WinRT

2012년 Windows 8에서 처음 나온 API 셋(set)이며 줄여서 WinRT라고도 한다. 모바일 환경에 대응하기 위하여 만들어졌다. 모든 WinRT API는 C++로 작성되었으며, 이는 수십년 전에 만들어진 Win32 API가 C언어로 작성되어 객체지향적 프로그래밍이 힘들었던 단점을 해결했다.(물론 MFC라는 C++ 래퍼가 나오긴 했지만 이것도 버려진지 10년이 넘어 쓸 때마다 사람 미치게 만든다.) 또한 C++로 작성되어있다는 것은 모든 WinRT API가 네이티브 런타임이라는 것이고, 이는 속도와 전력 소모에 이득이 되는 구조이다.

https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/01/29/43/2626.Win8%20WinRT%20Architecture.png

WinRT API는 다음과 같은 구조로 되어있으며, 네이티브 개발자를 위해 C/C++를 지원하고, 닷넷 개발자를 위해 C#/Visual Basic, 웹 개발자를 위하여 JavaScript로 프로그래밍을 할 수 있는, 여러 언어를 지원하는 런타임 API이다. 또한, 자주 쓰는 코드를 Windows Runrtime Library(줄여서 WRL)라는 라이브러리로 만들면, 라이브러리를 만든 언어와 상관없이 C++, C#, Visual Basic, JavaScript 모두 호출할 수 있다. 예를 들어 C++로 만들어진 라이브러리를 포함시킨 후 여기 안의 C++ 함수를 JavaScript로 호출할 수 있다. 또한, Windows RT 출시와 함께 모바일에서 강세를 보이는 ARM을 지원한다. 모든 Windows Runtime 앱은 마이크로소프트 스토어(구 Windows 스토어)에서만 배포할 수 있다. 이는 iOS와 같은 정책이다. 모바일에서도 빠르게 돌리기 위해 UI 쓰레드와 논-UI 쓰레드가 분리되어 있고, NT 커널은 항상 UI 쓰레드를 최우선으로 돌린다. 그리고 처리시간이 50ms가 넘어가는 모든 WinRT 함수는 비동기식으로 "강제로" 쓰게 하여 멀티쓰레드 코딩을 강제한다.

Windows 8 출시 때에는 Windows Rumtime 앱을 Windows 8/RT에만 쓸 수 있고, Windows Phone 8에는 종전의 실버라이트 기술을 써야 했다. 하지만 Windows 8.1/Windows Phone 8.1이 나온 후에 대부분의 로직 코드를 공유하면서 UI만 재설계하면 된다. 이는 두 OS의 커널이 같기 때문에 API의 상당부분을 공유할 수 있기 때문이다.

2015년 Windows 10이 출시된 이후 WinRT가 Universal Windows Platform으로 대체되면서 존속되고 있다.

네이티브 앱을 만들기 위해 가장 선호되는 언어이다. C가 더 빠르기 하지만 객체 지향 개념이 없어 앱 개발에 힘들어 C++을 쓴다. UI는 C#, Visual Basic에서도 같이 쓰는 XAML이란 언어를 쓰는데, 이는 데스크탑 닷넷 WPF 프로그램을 만들기 위해 만들어진 마크업 언어이다. 이를 통해 UI를 만들려고 Win32 API와 MFC를 쓸 때 생각나던 악몽과 같은 경험은 많이 덜 수 있었다. 기존 Win32 포팅을 편하게 하기 위해 Win32 API의 서브셋을 WinRT에도 그대로 사용할 수 있고, 게임을 위하여 DirectX 11.1 API를 지원한다. 하지만 현재 상황으로 볼 때, C++이 사용되는 경우는 보통 게임 또는 있던 C++ 코드를 재활용하거나, 속도가 극히 중요한 경우를 빼면 C++를 주로 사용하는 경우는 없는 것 같다. 주의할 점은 C++ 코드가 포함되면 빌드를 할 때 x86, x64, ARM을 각각 빌드해서 Windows Store에 제출해야 한다는 것이다.

Windows API와 Windows Runtime은 모두 C, C++ 개발을 위한 헤더와 라이브러리를 제공한다. 그러나 Windows Runtime 에서만 추가된 라이브러리가 일부 존재하며 이 인터페이스를 사용 할 때 UWP 앱은 바로 사용하면 되지만 Win32의 경우 기본적으로 COM 인터페이스를 사용하여야 한다.
다만 Windows Gaming Input 와 같이 Windows Runtime에서만 사용이 가능한 인터페이스가 있으나 일부 개발자들의 요청으로 TH1 이후 COM을 사용하지 않고 Include만으로 사용할 수 있도록 변경된 경우가 있다.

기존의 닷넷 개발자들은 아마 친숙해할텐데, 이는 WPF 프로그램을 만들 때 쓰던 XAML을 그대로 쓰기 때문이다. 하지만 디자인 언어가 대격변하여 구조와 작동원리 빼면 거의 대부분이 바뀌었다. 빌드시 IL로 컴파일되어 어느 아키텍처나 똑같은 IL을 CLR로 돌리기 때문에 프로그래머가 아키텍처를 신경쓰지 않아도 된다. Windows 8에서 .NET Framework 4.5가 포함되었는데, Windows Runtime C#/VB 앱은 .NET 4.5의 간소화된 버전에서 돌아간다. C++보다 좀 느리고 전력소모가 크다는 단점이 있다.

웹 개발자들을 위해 지원하는 언어이고, UI는 HTML/CSS로 작성되어 이론적으로는 웹페이지 코드(비표준 코드, 플러그인 코드가 없다는 가정하에)를 복사, 붙여넣기하면 웹페이지 그대로 보여준다. JavaScript 앱은 Internet Explorer 10의 차크라 엔진 가상머신 위에서 돌아가며, 작업표시줄에 보면 앱 썸네일을 보여주는 WWAHost.exe이 그 증거이다. UI는 보통 SDK와 같이 제공하는 WinJS라는 라이브러리를 이용해 작성하며, 이를 통해 Windows Store 앱 디자인을 구현할 수 있다.

크로스 플랫폼 앱이란 것은 하나의 코드로 여러 OS용 앱을 만드는 것으로, 최적화에 문제가 있지만 여러 OS에 배포하고 싶을 때 버전 관리가 쉽고, 각 OS를 위해 각각 팀을 만들어 개발하는 것 보다 비용도 저렴하게 되어 많이 뜨는 방식이다. 마이크로소프트 스토어 앱의 부족을 해결하기 위해 이런 크로스 플랫폼 미들웨어를 적극적으로 지원하고 있다.

C#으로 Android, iOS, Windows, macOS 앱을 만들 수 있는 플랫폼이다. Windows에는 .NET Framework을 쓰고, iOS와 Android는 .NET의 오픈소스 버전인 모노 위에서 돌아간다. MS가 .NET Framework를 오픈소스로 풀어서 모노 코드의 퀄리티가 급상승하고 있어 생각보다 꽤 괜찮다. 또한 최적화를 위해 C++ 코드가 필요하면 C++ 코드를 C#의 P/Invoke로 부를 수 있고, 각각의 OS에 GCC, Clang, Visual C++ 등의 컴파일러로 따로 컴파일되는 방식으로 쓸 수 있다. Xamarin IDE를 설치 후, Xamarin for Visual Studio 확장 기능을 설치하면 Visual Studio에서 Android, iOS 앱을 C#으로 개발할 수 있다. 단점은 Xamarin에 따로 라이센스 비용을 내야하고, 코드 샘플 지원이 적은 문제가 있다.

Unity나 Cocos2d-x 같은 게임 엔진들이 Windows Runtime을 지원한다. 이를 통해 버튼 하나로 iOS, Android 게임을 Windows Store 게임으로 만들 수 있다. 물론 최적화 및 테스트는 다시 해야 하지만 이거 덕분에 윈도우 스토어에 의외의 게임들이 올라와 있는 걸 가끔 볼 수 있다. HD 시절 이전 GTA 게임들 이라든지...

JavaScript로 Android, iOS, Windows 앱을 만들 수 있는 프레임워크이며, 플러그인을 통해 네이티브 API(알림, 카메라 등 보통 웹에서 접근할 수 없는 것들)에 접근할 수 있다. 웹페이지 코드를 많이 재활용할 수 있다는 것이 강점이다. 단점은 각 OS의 웹 렌더링 엔진을 모두 신경써야 하고, 속도가 네이티브 앱들보다 느리고, 전력 소모가 크다는 점이다.