일단 NativeCode인 C와 C++는 속도가 빠르다는 점은 알고 있습니다만,
NativeCode를 써야만 하는 이유 중에는 Managed언어(C#, JAVA 등)에서 없는 API를 제공한다고 하네요.
대표적으로 뭐가 있을까요? MSDN에서는 다음 3가지 이유가 있다고합니다.
ㆍ하드웨어 또는 운영체제 관리 기능 → 예를들면 뭐가있을까요? DirectX도 GPU 제어니까 포함될까요?
ㆍABI를 생성 → ABI가 뭘까요? 버전호환 같은 걸까요?
ㆍCOM 구성요소 등록 가능 → COM(Component Object Model)은 아무리 봐도 어렵습니다. 다룬적이 없어서…
혹시 설명해주실분 있을까요? 아니면…
이 3가지의 심플한 예제나 도움될만한 레퍼런스 추천해주시면 감사하겠습니다…(_ _)
a. 닷넷의 내장 API들이 윈도우나 리눅스의 모든 제어 기능을 다 래핑하는 것은 아니어서 네이티브 호출이 분명히 필요한 상황이 있습니다. 일단 윈도우의 경우 생각나는 것은 지금 사용자 화면에 떠 있는 창들을 열거하는 부분이나, Microsoft Detours 같은 도구를 이용해서 Win32 API 호출을 가로채는 것과 같은 기능은 닷넷이 제공하는 기능이 아니지요.
b. ABI는 Application Binary Interface입니다. 바이너리 수준에서 호환성을 보장한다는 것을 ABI 호환성이라고 이야기하는데, C 언어로 동적 모듈을 만들면 대체로 Java나 C#을 포함해 Golang, Rust, Python 등 다른 모든 언어들이 C 언어로 만든 모듈을 부를 수 있습니다. 최근에 닷넷은 NativeAOT 프로젝트를 통해서 C 언어처럼 동적 모듈을 만들어주는 기능을 개발하고 있습니다. (즉, 닷넷 런타임 없이 MSIL을 곧바로 대상 CPU 기계어로 뽑는 기능입니다.)
c. COM은 닷넷보다 앞서서 도입된 프로그래밍 패러다임입니다. C 언어 함수 형태만으로는 개체 지향 형태의 프로그래밍 패러다임을 프로세스 경계를 넘어서 전달하기 어려운 한계가 있었고, 이를 극복하기 위해 VTable이나 Type Library 같은 컨셉을 사용합니다. 닷넷에서는 이것을 리플렉션과 어셈블리라는 개념에서 비슷하게 연상할 수 있고요. 그 후로 나온 COM+나 DCOM은 요즈음 우리가 보고 있는 gRPC나 닷넷 프레임워크 초창기의 닷넷 리모팅을 연상할 수도 있습니다.
일단 생각나는 것만 적어보면 이런 정도인데, 혹시 더 궁금하신 내용이 있다면 적어주시면 감사하겠습니다. (+ 저도 이 주제를 다룬지 오래되어서 잘못 알고 있는 내용이 혹 있을지 모르겠습니다. 친절하게 알려주시면 감사하겠습니다.)
감사합니다.
정말 어려운 내용을 잘 정리해주셨네요.
제 내공이 쌓이면 그때 질문도 떠오를 것 같아요 ㅎㅎ
그런데 사실 이 질문을 올렸던 이유는 C++/WinRT 를 써야될 이유에 의문을 가졌기 때문입니다. WinRT는 UWP의 기반이 되는 라이브러리로 Win32 API를 모던 C++로 구현했답니다. 그래서 관리언어인 C#에서 곧바로 WinRT를 통해 Win32 API를 사용할 수 있다고 합니다. (제가 알기로는…)
그래서 NativeCode의 빠른 속도 외에 특정 영역의 API를 독점적으로 가지는지 궁금했었어요.
어쨋든 큰 도움 되었습니다 !
WinRT는 윈도우 8 이후로 MS가 모바일 데스크톱 통합을 목표로 차세대 API라고 밀던 과거의 잔재입니다.
현재는 WinRT에 대한 래퍼가 공식적으로 닷넷, Rust, C/C++에서 모두 마이크로소프트가 지원하고 있고, 사용하는 입장에서는 고민하지 않아도 되는 부분이 되었습니다. ㅎㅎ
덧붙여서, WinRT를 거쳐야 부를 수 있는 기능은 또 한정적입니다. 개인적으로 이렇게 차세대를 들먹이면서 API 파편화를 일삼은 MSFT의 결정은 참 실망스럽습니다.
그나마 요즈음은 다시 제대로된 방향으로 가는듯 보입니다.
이 글의 카테고리는 프로그래밍 언어와 닷넷 런타임 게시판이 적절하다고 판단하여 이동했습니다.
제가 이해한게 맞다면 파편화란게 .Net Core 5의 일부 기능을 WinRT(Windows API)로 분리시킨 것이라고 봐도 될까요?
음 윈도우 개발이 아직 생소해서 (역사는 잘 모르기 때문에) MSDN의 저 내용은 이해가 안되네요 ㅎ 왜 분리시켰을까요?
이건 닷넷 핵심부가 최대한 OS나 플랫폼에 독립적이고 중립적으로 만들기위한 결정인것 같아요. 
흠… 그렇군요…헤헤…
답변 감사합니다. 
