微软在UWP中提供了一组丰富的API能够满足99%的应用的需求，然而在那剩下1%的情况下找不到桌面API的替代品是很棘手的，正如我上一篇文章里提到的CreateFile，就不属于微软在UWP中允许使用的API。
实际上WACK的API检测是个没什么用的东西，因为它是通过读取PE导入表，以及 .NET程序的P/Invoke签名的方法来判断一个App是否使用了不允许使用的API。因此只要调用LoadLibrary就能轻松绕过。
问题在于LoadLibrary(Ex)本身不被允许调用，微软表示替代品是LoadPackagedLibrary，而这个API在调用时会检测路径是否在appx内，如果不在就直接报错。（太愚蠢了）因此首先我们要设法获得LoadLibraryEx的地址，在此之前先获取kernel32.dll或kernelbase.dll的地址。
关于UWP的历史，其起源是Microsoft在Windows 8中引入的Metro apps。（后来又被称作Modern apps, Windows apps, Universal Windows Apps等）无论是从目的还是从效果上看，这一类应用模型都与iOS/Android比较相似，是为了更有利于移动平台生态的发展设计的。
然而UWP目前面向的最大的用户群体是Windows桌面用户，只用UWP实现一个程序就会出现很多feature无法实现的问题，因此这种情况下，让用户安装并运行一个普通权限的后台进程，使用UWP做UI与之通信就成为了一种选择，毕竟UWP的C#/XAML性能比WPF好得多，分发/支付上也比桌面程序方便不少，虽说原则上微软并不允许商店应用与桌面应用互相通信。
几个月前在翻MSDN时发现Microsoft已经允许在Windows Store Apps（即UWP）里使用Chakra的API了。这意味着大家终于可以光明正大地在app中调用Javascript。//另外UWP允许JIT了所以你自己移植个V8上去其实也行
在8.x时代，Chakra是被标记为Desktop only的API，想要在Store apps里使用js，要么整个App使用HTML/js编写，要么使用WebView调用。前者显然不符合主要使用C#/XAML编写UI的前提，后者麻烦的要死，不好用。
UWP写起来真舒服（棒读）
使用Chakra之前需要较为深入地了解Chakra API，COM和JavaScript。其实不了解直接照抄代码拿着用也没什么不好，就是出了错之后不好排除。
做播放器时一般人多多少少都会遇到点字符乱码的问题，这些乱码基本都是出在mp3等老旧的格式上。这大概都是因为这些音频文件使用不遵循编码标准的软件制作而成。解决方法似乎也不怎么好（至少我的乱码mp3没有办法解决），不过MLang API作为Windows系统自带的API（Universal App可用）是非常方便好用的窄字符串编码检测方式，特定情况下非常好用。
使用方法非常简单：
#include <MLang.h>
HRESULT DetectCodepage(char* text, int* codePage) {
IMultiLanguage2* iml;
HRESULT hr = CoCreateInstance(CLSID_CMultiLanguage, NULL, CLSCTX_INPROC_SERVER, IID_IMultiLanguage2, (LPVOID*)&iml);
if (SUCCEEDED(hr)) {
DetectEncodingInfo info;
int size = strlen(text) + 1, cnt = 1;
hr = iml->DetectInputCodepage(0, 0, text, &size, &info, &cnt);
if (SUCCEEDED(hr)) {
*codePage = info.nCodePage;
iml->Release();
return S_OK;
}
}
return hr;
}
获得Code Page之后就可以用MultiByteToWideChar之类的API将窄字符转换为宽字符了。
其他相关内容可以参考MSDN： https://msdn.microsoft.com/en-us/library/aa741220(v=vs.85).aspx