DotNetSdkRoot 路径不正确解决方案

.NET Framework SDK 4.6.1 升级安装时未能正确更新路径,导致编译错误,例如找不到 clrdata.h 等。
微软喜欢把变量值抽象许多层之后写在各种隐蔽位置,调试多次后终于找到,记载如下。

C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP\10.0.10586.0\UAP.props
在这个文件中将两处 4.6 替换为 4.6.1。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\14.0\14.0

将 FrameworkSDKRoot 和 SDK40ToolsPath 中的 4.6 替换为 4.6.1。

另外 Windows SDK 8.1 升级到 10.0.10240 / 10.0.10586 时也有类似的问题,导致新项目的默认 SDK 版本停留在 8.1,但可以通过项目菜单中的“重定解决方案目标”暂时解决。待有空时再寻找永久解决方案。

C++11:简化动态调用外部函数

#define INIT_DLL_FUNCTION(dll, name) name = reinterpret_cast<decltype(name)>(::GetProcAddress(::LoadLibrary(_T(dll)), #name));
NTSTATUS(WINAPI *NtOpenDirectoryObject)(
	_Out_  PHANDLE DirectoryHandle,
	_In_   ACCESS_MASK DesiredAccess,
	_In_   POBJECT_ATTRIBUTES ObjectAttributes
	);
INIT_DLL_FUNCTION("NTDLL.DLL", NtOpenDirectoryObject);
NtOpenDirectoryObject(...);

如何假装能正确处理 Content-Disposition

Content-Disposition 可能是浏览器、下载器等应用最难正确处理的东西之一。
实际上谁也没能做到完全正确处理,那么怎么在大多数情况下正确处理呢?

标准版的是这样的:
Content-Disposition: attachment; filename="attachment.zip"
这个是完全符合 RFC 2183 规范的版本,基本上也只能在 RFC 2183 里见到了。

Google 决定用正则表达式匹配:
attachment;\s*filename\s*=\s*\"([^\"]*)\"
这个是完全匹配了标准格式,理想状态下成功率是 100%。

于是有网站决定这样发:
Content-Disposition: attachment; filename=attachment.zip
不带引号,匹配失败了。

大概是意识到失败率太高,Google 又修改了一下:
attachment;\s*filename\s*=\s*(\"?)([^\"]*)\1\s*$

于是有网站决定这样发:
Content-Disposition: attachment; filename=attachment.zip; filename*=UTF-8''%E9%99%84%E4%BB%B6.zip
不带引号,匹配错了。

于是又有人放弃了正则表达式,使用简单的 Lexer 切割出分号分隔的 filename 字段。

于是有网站决定这样发:
Content-Disposition: attachment; filename=附件.zip
这种方法的精妙之处在于无法预测它使用了什么编码方式。
这个网站特别注意了绝对不在 Content-Type 中包含任何编码信息,以防被嗅探到正确的编码。
虽然标准规定了必须是 UTF-8 编码,但谁会去看标准呢?

不过如果他们看了标准,发送方式可能会变成这样:
Content-Disposition: attachment; filename="=?ISO-8859-1?Q?a?="
这是 RFC 2047 规定的 Encoded Word 编码方式。

或者干脆组合起来,比如这样:
Content-Disposition: attachment; filename*=UTF-8''%E9%99%84%E4%BB%B6.zip; filename="附件.zip"

这还是假设网站发送的内容都是正确的情况下。
所以,有时候还是假装没看见好了。

顺带一提,如果发回的内容带有斜线等神奇字符,一不小心可就是路径遍历漏洞了。万一还放在了某些敏感位置,可能就开机启动了呢。

暂时解决 Visual Studio 2013 RTM 无法将嵌套 lambda 函数自动转换为 stdcall 的问题

VS2013 RTM 对于嵌套 lambda 支持不是很好,若希望转为 API 的 stdcall 形式,会出现编译错误。

例如:

::EnumWindows([](HWND hWnd, LPARAM lParam) {
    ::EnumChildWindows(hWnd, [](HWND hWndChild, LPARAM lParam) {
        return TRUE;
    }, NULL);
	
    return TRUE;
}, NULL);

编译这段代码会报错:

error C2664: “BOOL EnumChildWindows(HWND,WNDENUMPROC,LPARAM)”: 无法将参数 2 从“int (__cdecl *)(HWND,LPARAM)”转换为“WNDENUMPROC”

将里层 lambda 暂存到一个 stdcall 的函数指针里,可以暂时解决问题。

::EnumWindows([](HWND hWnd, LPARAM lParam) {
    WNDENUMPROC callback = [](HWND hWndChild, LPARAM lParam) {
        return TRUE;
    };

    ::EnumChildWindows(hWnd, callback, NULL);

    return TRUE;
}, NULL);