事情的起因是，想找个跨 Windows 和 Mac 的构建方案。第一考虑自然是 CMake，毕竟基本上是事实标准了。

但是研究了一下 Modern CMake，也就是以 target 为核心的理念。但发现看了好几天文档，也折腾出了可用的东西，但仍然是没梳理清楚什么理念、原理。然后 CMake 本身语法就很复杂，再加上搞 target 一套概念，要给 target 设置各种属性之类的，有点强行 OOP 的感觉……但其实我们只是需要一个 include_dir 和 lib_dir 而已，其他都是浮云~

但如果退回到传统模式，不用 Modern 概念呢，好像可以将就，但第一不去用一个工具的最新模式，好像有点不上进的感觉（python 2 除外）；第二，CMake 的两大痛点——语法特立独行、文档晦涩难懂——还是让人有点不爽。

那跳出来看别的选择呢？目前相对成熟的也只有 Google 的 gn+ninja 方案了。gn 这套东西在 Chromium 里是完全配置好的，用起来还算顺手，但要是独立拿出来呢，就没那么便宜了。关键是它的 toolchain 是要自己定义的。

之前还在公司搞客户端的时候，大家就从 Chromium 里面把 build、build_overrides 等等东西全部拷出来，好家伙，几百 MB 甚至上 G。但是公司里嘛，没人管干不干净，怎么快怎么来。后来又看到 Google 自家的 Crashpad 里面也用了这套构建，但工具链被简化了一下，叫 mini_chromium。这个比 Chromium 里的小多了，是可以拿过来直接用的，缺少一些配置可以自己加。但是呢，像我们这种洁癖，仍然是受不鸟的。所以呢，我们要干干净净的建立一套工具链。

构建系统安装

首先，我们明确定位。gn 和 ninja 都是开发机上需要预装的，不是软件提供的。Chromium 的搞法是自己提供，gn 的文档也说让开发者提供工具。但这套思路跟传统的理念是冲突的。同时，自己安装工具成本是比较低的：

• linux
  • ninja 在主流包管理系统里已经有了，包名可能是 ninja 或 ninja-build，直接安装就可以
  • gn 在部分包管理系统有，尝试包名 gn 或 gn-build 等，没有的话可以下载二进制版本，或者从源代码自行编译
• mac
  • ninja 在 brew 里包名叫 ninja，在 MacPorts 里包名叫 ninja-build
  • gn 在 brew 里没有，可以下载二进制版本；在 MacPorts 里叫 gn-devel
• win
  • ninja 可以在 GitHub 下载二进制版本，gn 可以在 gn 官网下载二进制版本

自己下载的设置到 PATH，测试 gn --version 以及 ninja --version，能运行即可

目标

希望做到提供一个 git repo，使用者 clone 到自己项目的 build 目录，然后使用者只要在 .gn 文件里配置

buildconfig = "//build/BUILDCONFIG.gn"

就可以使用我们提供的工具链，在 PC 三端进行构建。

使用者的唯一负担就是编写自己的 BUILD.gn

工具链搭建

首先我们看 gn 的文档，以及它的例程 simple_build 里的工具链配置：

https://gn.googlesource.com/gn/+/HEAD/examples/simple_build/build/toolchain/BUILD.gn

这个是可以直接用的，只不过只有 linux 端（当然 mac 也能用）。我们再结合 chrome 里的工具链配置，进行一些完善。

基础概念

首先我们了解 gn 体系需要的最小配置是什么。

第一，它需要在根目录写一个 .gn 文件，在里面定义 buildconfig，指到另一个文件，一般是

buildconfig = "//build/BUILDCONFIG.gn"

第二、BUILDCONFIG.gn 里面需要设置默认工具链，也就是写一行

set_default_toolchain("//build/toolchain:gcc")

第三、定义工具链，如上例的 //build/toolchain:gcc。

需要在 build/toolchain 下建立 BUILD.gn 文件，内容是

toolchain("gcc") {
	# ...
}

最后在 toolchain 里定义各种 tool。

工具链中的工具

这部分文档在这里：https://gn.googlesource.com/gn/+/main/docs/reference.md#func_tool

简单复述一下，可被定义的工具有：

• 编译工具:
  "cc": C 编译器
  "cxx": C++ 编译器
  "cxx_module": 支持 module 的 C++ 编译器
  "objc": Objective C 编译器
  "objcxx": Objective C++ 编译器
  "rc": Windows 资源脚本编译器
  "asm": 汇编器
  "swift": Swift 编译器
• 链接工具:
  "alink": 静态库链接器
  "solink": 动态库链接器
  "link": 可执行文件链接器

（其他的就先不看了）

我们来看一下 https://gn.googlesource.com/gn/+/HEAD/examples/simple_build/build/toolchain/BUILD.gn 的一些关键配置：

toolchain("gcc") {
  tool("cc") {
    command = "gcc -MMD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_c}} -c {{source}} -o {{output}}"
    outputs = [ "{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o" ]
    # ...
  }
  tool("cxx") {
    command = "g++ -MMD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_cc}} -c {{source}} -o {{output}}"
    outputs = [ "{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o" ]
    # ...
  }
  tool("alink") {
    command = "rm -f {{output}} && ar rcs {{output}} {{inputs}}"
    outputs = [ "{{target_out_dir}}/{{target_output_name}}{{output_extension}}" ]
    # ...
  }
  tool("solink") {
    command = "g++ -shared {{ldflags}} -o $sofile $os_specific_option @$rspfile"
    outputs = [ sofile ]
    # ...
  }
  tool("link") {
    command = "g++ {{ldflags}} -o $outfile -Wl,--start-group @$rspfile {{solibs}} -Wl,--end-group {{libs}}"
    outputs = [ outfile ]
    # ...
  }
  tool("stamp") {
    command = "touch {{output}}"
  }
  tool("copy") {
    command = "cp -af {{source}} {{output}}"
  }
}

可以看到，cc 和 cxx 执行 command 后，生成 .o 文件，然后这些 .o 文件可以作为 alink、solink、link 的 inputs，被它们 command 继续使用，最后输出静态库、动态库以及可执行文件。

其余属性可以查文档了解含义。

对比 Chromium 中的配置

Linux

主要配置在这里：https://source.chromium.org/chromium/chromium/src/+/main:build/toolchain/gcc_toolchain.gni

也是 gcc 的，与 simple_build 里的大同小异，没有特别的。

Mac

主要配置在这里：https://source.chromium.org/chromium/chromium/src/+/main:build/toolchain/apple/toolchain.gni

区别有：

• 用 clang 系列编译工具，而不是 gcc
• alink 不是用 ar，而使用 libtool
• solink 的默认扩展名改成了 dylib
• 用了一个 linker_driver.py 来支持生成 dSYM，在里面调用了 dsymutil 和 strip

Win

• 编译用 cl，静态库链接用 lib，动态库和可执行文件的链接用 link
• lib_switch = ""，lib_dir_switch = "/LIBPATH:"；前两者 lib_switch = "-l"，lib_dir_switch = "-L"

建立我们的工具链

基本上是根据上面分析的要点配置，最终结果在此：https://github.com/Streamlet/gn_toolchain

新增的一些差异有：

• 增加全局参数 is_debug，可以在 gn gen out --args="is_debug=true"传入。默认 is_debug 为 false，开启所有优化。

• mac 下生成 dSYM 不使用 python 脚本，直接是 $ld ... && dsymutil ... && strip

• mac 下加了一个 template：app_bundle，用来生成 xxx.app，主要配置来自于 create_bundle 文档里的例子

• win 下增加了一些配置集

  • 动态/静态链接 CRT：//build/config/win:console_subsystem、//build/config/win:static_runtime

  • 控制台程序、Win32 程序：//build/config/win:console_subsystem、//build/config/win:windows_subsystem

    这个其实一般情况下用不着，只要入口函数是 main/WinMain，link 默认就是控制台程序/Win32 程序

  • XP 支持：//build/config/win:console_subsystem_xp、//build/config/win:windows_subsystem_xp

    具体实现是链接参数加 /SUBSYSTEM:CONSOLE,5.01 或 /SUBSYSTEM:WINDOWS,5.01。关键是后面的版本号 5.01，为了加版本号则必须指定子系统名称，所以分了 console_subsystem_xp 和 windows_subsystem_xp。又，xp 这里提供了两个 subsystem 的配置集，非 xp 也提供两个。

    但是我们没有加 _WIN32_WINNT=0x0501、WINVER=0x0501、_USING_V110_SDK71_，也没有指定必须使用 7.0 版本的 SDK，这些都是非必须的，只要不用到 XP 以后添加的 API 即可。使用者可以在自己的 target 里面定义这些宏。

使用案例

提供一个使用案例：https://github.com/Streamlet/gn_toolchain_sample

因为它以 git submodule 形式引用了 https://github.com/Streamlet/gn_toolchain，所以 git clone 以后，需要 git submodule update --init一下。

然后在根目录执行：（确保 gn 和 ninja 已经在 PATH 中）

gn gen out
ninja -C out

即可。

Mac 下会额外生成一个 objc 项目 objc_console_application 以及一个 app_bundle：ns_application.app。

Win 会额外生成一个 Win32 项目 win32_application。

Win 下需要先执行一下 Visual Studio 带的命令行环境，如 VS 2022 Community 的 “x64 Native Tools Command Prompt for VS 2022”，cl 等工具才会可用。

如果要测试 XP（32位），用“x86 Native Tools Command Prompt for VS 2022”进入，CD 到项目目录，执行：

gn gen out --args="target_cpu=\"x86\""
ninja -C out

总结

我们只用几十 KB 的大小完成了跨端支持，是很轻量的一个配置。如果您觉得实用并认可这种方式，欢迎一起来维护、完善。

这次是因为傻逼大微软改了 System32\IME\shared 里的东西，导致旧系统拷过来的文件与 System32\IME\shared 的东西不兼容了。解决方式很暴力：从以前的版本复制 System32\IME\shared 过来。

下载：https://www.streamlet.org/software/mspyforever/

（原发于 GitHub Pages，2018-10-13 13:36:04）

有 A、B 两个窗口，A 是 B 的 Owner，B 不激活不抢焦点。在 B 的 WM_LBUTTONDOWN 的时候，设置 A 窗口为 Capture；在  A 的 WM_LBUTTONUP 的时候 ReleaseCapture。

操作是，在 B 上按下鼠标，然后一直按住鼠标飘啊飘。在某一时机把 B 干掉，继续动鼠标。此时 A 还在，并且 A 仍然是 Capture 状态，但是 A 收不到 A 可视范围外的 WM_MOUSEMOVE 了！在全过程中 A 也没有收到 WM_CAPTURECHANGED。

下面是栗子：

http://pan.baidu.com/s/1mgurJIS

求解释。求解决。谢谢~！

[1]十个步骤找回 Win8 中的微软拼音新体验模式

[2]发布个工具，一键恢复Win8/8.1中的微软拼音长句模式（新体验模式）

在 [1] 中，我们找回了 Win8 里的微软拼音新体验模式；在 [2] 中，依照 ePig 提供的方法，我们在 Win8.1 中也搬回了微软拼音新体验模式，但留下了一点遗憾，不支持 Metro 应用。

（其实还有一点，没有显示图标。）

原本我觉得无所谓，因为我反正不太用 Metro 应用，Metro 下就用自带的微软拼音简捷模式好了。可是，可是，输入法管理器中，比如保留一个兼容 Metro 的输入法，导致桌面下也比如保留简捷模式了，这样切换输入法经常切错，离所谓“一个输入法”的伟大目标相差甚远。于是乎，不能忍。然后昨天起来看了下这个问题。

原先微软拼音输入法的一个不知什么的GUID是 {81d4e9c9-1d3b-41bc-9e6c-4b40bf79e35e}，该 GUID 代表的输入法下有两个输入模式，新体验和简捷。（这个构架和相关内容我不是很懂，具体请去查阅 TSF (Text Service Framework) 框架相关文档。） Win 8 下只是删除了新体验模式的那个注册表项并对注册表项加权限保护达到禁用目的。Win8.1 下的变化是，老的文件被删除了，且 {81d4e9c9-1d3b-41bc-9e6c-4b40bf79e35e} 被用作新的微软拼音的 GUID 了，里面也不再分两个模式了（其实只有原先的简捷模式）。按照 ePig 提供的方法，从 Win8 中复制相关文件，并把文件中的 GUID 改了，重新注册进去。这边我在一键恢复工具所带的文件中是把 GUID 末尾 e 改为了 f，完整的就是 {81D4E9C9-1D3B-41BC-9E6C-4B40BF79E35F}。按道理应该完全兼容才是，起码 Win8 下是支持 Metro 的。微软拼音很早就是 TSF 框架了（而不是 Imm），据我之前的了解，要支持 Metro，输入法使用 TSF 框架就好了。

想不通的情况下，就来比较下 Win8.1 下自带的微软拼音（简捷模式）和我们新加的微软拼音新体验模式的注册表项差异：

发现自带的多了几项（红框部分）。于是仿照着把这些补上去，结果确实不显示“仅适用于桌面版”了，可是好像也没法输入了……于是每次只加一项，依次试过去（穷举法，鄙视）。最后发现前两个 ，也就是 {13A016DF-560B-46CD-947A-4C3AF1E0E35D}、{25504FB4-7BAB-4BC1-9C69-CF81890F0EF5} 可以要，最后 {74769ee9-4a66-4f9d-90d6-bf8b7c3eb461} 不能要。

再看下 Win8 的，果然也是有这两个 Category 的：

然后这事情就算成了：

一键工具已更新，下载页面：http://www.streamlet.org/Software/MSPYForever/

那么这两个 GUID 到底是什么呢？Google 一下……

关于前者，http://msdn.microsoft.com/zh-cn/library/windows/apps/hh967425.aspx#set_compatibility_flag 中有说明如下：

声明兼容性

IME 通过使用 ITfCategoryMgr::RegisterCategory 为其 IME 注册类别 GUID_TFCAT_TIPCAP_IMMERSIVESUPPORT 来声明其兼容 Windows 应用商店应用。

其中 GUID_TFCAT_TIPCAP_IMMERSIVESUPPORT 就是 {13A016DF-560B-46CD-947A-4C3AF1E0E35D}。

{25504FB4-7BAB-4BC1-9C69-CF81890F0EF5} 也是个预定义的值，叫做 GUID_TFCAT_TIPCAP_SYSTRAYSUPPORT，按字面理解，系统托盘支持，可是查不到官方说明啊，http://msdn.microsoft.com/en-us/library/ms629012.aspx 这一页啥也不说，是不是bug……

不管怎么说，问题是解决了。大快人心。

再顺便黑下大微软。

看这张图，我在写代码或写Word或者写别的文字，开着中文语言下的中文输入法（写代码怎么会开中文？不要在意这些细节……），然后来了条 QQ 消息。我去任务栏点企鹅图标。结果刚点下，因为任务栏、桌面是英文语言下的美式键盘，输入法指示器变为 ENG，缩短了，企鹅图标跑右边去了，点空了！！！

正因为如此，我以前总是把英文语言删掉，只有中文语言，下面一个输入法，靠 Shift 在输入法内切换中英文。可是 Shift 很容易误操作有木有。最佳的方式还是中文语言下的美式键盘……这个问题很早之前研究过几个小时，但没啥结果，后来想，如果真的没办法了，干脆写一个空的输入法原样输入输出，叫做“美式键盘”得了。为啥中文下就不给键盘布局呢？为什么呢为什么呢为什么呢？

昨天又去网上搜了下，结果高人已经给出了方法了，不知道哪篇是原创，就不引用了，有兴趣的自己搜。这里还有个半官方的出处：http://answers.microsoft.com/zh-hans/windows/forum/windows_8-ime/windows-8%E7%9A%84%E8%BE%93%E5%85%A5%E6%B3%95/91917117-c5fd-4c61-ac2e-da0dd29d12fc。但其实美式键盘没有图标，会显示“简体”，所以也会有长短变化。最佳的方法还是恢复成语言栏的样子：

这下同在中文语言下了，Ctrl+Shift 切输入法，怎一个舒服了得~！至此，Win8、Win8.1 的输入法问题对我个人而言已经全部解决了，可以大规模重装系统了。

忍不住再黑下大微软：http://answers.microsoft.com/zh-hans/windows/forum/windows_8-ime/%E5%85%B3%E4%BA%8E%E4%B8%AD%E6%96%87%E7%89%88windo/b5c3190f-bb82-4855-97f0-00d6011e3e33，这个答非所问，是不是在搞笑？

首先贴个图，大家来一起念台词~

念完了木有？很激情澎湃义愤填膺有木有？

这事情最早追溯到前年 8 月的一篇文章《十个步骤找回 Win8 中的微软拼音新体验模式》，其实就是手工注册一个COM完事，只是傻逼大微软刻意弄了注册表权限来屏蔽，操作起来略微繁琐。到目前为止，Win8重装系统已经不下十次了，每次都是这样手工操作，我已经厌倦了。

另外还有Win8.1上的问题，由于傻逼大微软已经完全删除了文件，就没法这么搞了，就算从Win8拷过文件来，也无法简单注册使用。加上我对8.1非常非常不感冒，一直没去研究。前些天看到之前的那篇文章里 Charles Leigh 回复了两篇文章（ePig 那篇是原创吧貌似，感谢），提供了解决方案。于是上个周末到现在就捣鼓个一键恢复工具，方便自己以后重装用，也方便广大微拼党。

微拼党（包括我）孜孜不倦的追求微拼长句模式的情怀，让我非常感动。希望傻逼大微软看到我们的心声。别搞什么破词组输入法了，你搞不过本土这么多厂家的，你的下限也没有本土厂家低，唯一的优势可能就是没广告没弹窗了吧。至于输入算法什么的，在词组模式里面根本不足以体现得太多，长句模式才是考验啊。回头吧！

下载页面：http://www.streamlet.org/Software/MSPYForever/

CodePlex 项目页面：https://mspyforever.codeplex.com/

请微拼党们多传播。有 Bug 及时反馈。

2*2的会被弄成：

更大的图片，表现为右边缘和下边缘渐变：

GDI+自作聪明了……

解决方法：

Graphics g;

g.SetInterpolationMode(InterpolationModeNearestNeighbor);

g.SetPixelOffsetMode(PixelOffsetModeHalf);

效果：

特此记录。

参考资料：http://bbs.csdn.net/topics/310212346

微软拼音输入法的新体验模式，其实是微软拼音一直以来的主要模式。笔者从1.5版开始接触微软拼音以来就一直是这种模式，主要特点就是长句输入、二次确认，在第一次确认的时候，文字就进入仿佛实际输入区域，但是文字下面有虚线，此时我们可以用光标键左右移动，就像下图显示的一样：

而在输入拼音的时候，我们其实无需开启候选词窗口，也不用看屏幕：

输入完毕之后按空格，观察首选是否正确，如果正确的话再一次空格确认，否则按一下右光标键回到句首开始选词。非常方便，也显得很专业。

习惯于词组输入的同学可能喜欢时刻盯着屏幕出现的候选词，一旦有错立刻纠正选择。而长句输入则不必这样，输入整个句子，让输入法在整句的语境中替你选词，命中率会高很多，特别是在打长篇文章的时候，非常有用。

很多时候别人在看我输入的时候，发现屏幕上有错别字，会忍不住提醒我错了，但是当我最后确认的时候，往往又对了，会显得有一点点疑惑，但是通常不说。有趣的是，我在打别人名字的时候，他们发现一开始的错别字，也会忍不住提醒我错了，并且对输入法把某人的名字弄成另外一个字非常感兴趣，有时会以此"嘲笑"那个人。然后当我最后回来选词的时候，他们会"指责"干嘛一开始不选对的字……我已经习惯了。但是整句输入带来的便捷之处，大部分人是没法认识到的。所以我今天在这里花很大的篇幅介绍一下。

遗憾的是，微软拼音1.5、2.0、3.0都没人叫好。到Office2003的时候，因为"新体验"模式的出现，使得一部分人叫好，但那部分人其实还是把它当作词组输入法来用的。到Office2010出来的时候，又有一部分人叫好，实际上很大一部分人是为"简捷"模式叫好。到现在Win8成了简体中文语言下默认输入法，即便有强推的味道，但好多人还是叫好，而新体验模式的消失，却很少有人问津。

下面正式来看标题中提到的问题。Win8安装完毕后简体中文下只有一个微软拼音简捷，新体验模式不见了！！！

有需要的同学，请跟随笔者，一步一步找回新体验模式。

1、打开开始屏幕，在英文状态下输入regedit，然后回车，打开注册表编辑器。（遇到UAC提醒，请选择"是"）

2、在左侧展开目录树，一直到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP\{81d4e9c9-1d3b-41bc-9e6c-4b40bf79e35e}：

微软对这一项做了特殊的权限保护，它的权限和相邻的那几个不一样，我们要取得写权限。

3、右键单击它、选择权限，打开如下图的窗口：

4、单击"高级"，再打开一个窗口：

5、在所有者的右边点击"更改"，输入"everyone"或者当前登录用户名，按"确定"，并选中"替换子容器和对象的所有者"，然后按应用。（不要关闭这个窗口，等下我们还要改回来。）

6、然后点击左下方的启用继承（按了后该按钮变为禁用继承），并选中"使用可从此对象继承的权限项目替换所有子对象的权限项目"。最后按"应用"，遇到提示选择"是"。

现在，这个窗口变成这个样子了：

保留这个窗口，我们进行下一步。

7、打开开始屏幕，在英文状态下输入"cmd"，左侧出现"命令提示符"，右键点击选中它，再到屏幕下方点击"以管理员身份运行"，遇到UAC提示选择"是"。这样我们打开具有管理员权限的命令提示符窗口，工作路径位于System32目录。

8、输入"regsvr32 ime\imesc\imsctip.dll"，并按回车。

直到看到下图的提示，点击确定，关闭命令提示符窗口。

9、回到刚才的高级安全设置窗口，点击左下方的"禁用继承"按钮，这时出现下图提示：

选择第二项，"从此对象中删除所有以继承的权限"：

并选中"使用可从此对象继承的权限项目替换所有子对象的权限项目"，按"应用"，遇到提示选择"是"。

10、点击上方所有者右边的"更改"，输入"nt service\trustedinstaller"，按"确定"，并选中"替换子容器和对象的所有者"，然后按"应用"。

至此，我们将注册表权限恢复如初了。

打开输入法管理界面：

我们可以看到多出来的"Microsoft Pinyin NewExperience"了，它就是我们要找的新体验模式！

悲剧的是，貌似新体验模式在Metro界面下有问题，每次确认输入，光标都会回到最前面（注：确认这是当时新浪微博Win8客户端的Bug，不是输入法的问题，新浪微博貌似已经修正此问题）。也许是因为有这些Bug，微软才隐藏它的吧。不过，桌面模式下使用起来未发现任何问题哦。

（所有内容针对 VC 编译平台）

一、x86

二、x64

64位编译环境下，可以指定 __cdecl、__stdcall、__fastcall，但是编译器会忽略它们。两个显示指定了不同调用约定的函数不构成重载，而构成重定义错误。

稍微解释下，因为有可能有人会误会：放新线程里面去不就可以了？这没有解决问题。如此的话，你那个线程函数怎么写？或者线程函数里调用的某个任务函数怎么写？总之，多线程虽然总是出现在这些问题的解决方案中，但不是多线程解决了这个问题。嗯……不知道说清楚了没？

目前我心里的答案只有这一种模式：

bool DoTask(HANDLE hQuitSignal)
{
    while (!QuitCondition)
    {
        if (WaitForSingleObject(hQuitSignal, 0) == WAIT_OBJECT_0)
        {
            return false;
        }

        // Do something
    }

    return true;
}

其中，“// Do something”部分要细化到瞬间执行完成的细度。

但是我很困惑的是，如果这些任务很繁重，难道我必须每进行一些操作就 if (WaitForSingleObject(hQuitSignal, 0) == WAIT_OBJECT_0) 检查下吗？这样岂不是这种检测代码充斥在任务中了？

不知各位有何经验和体会，求教~

GUI框架，要做的事情我想大概是这么几步：

1. 实现回调函数的成员化。
2. 实现方便程度可接受的消息映射。
3. 确定上述核心部件的使用方式。
4. 制造大量的控件。

前三步要走的比较小心，第四步是体力劳动。

第一步，Windows下可参考的是MFC方式、WTL方式，以及利用Window相关属性中的某些空位。前不久刚初步看过WTL的机制，虽然当时没写GUI框架的打算，不过也有点技术准备的意思了。现学现用吧。这里一个可以预见的问题是64位兼容，现在没有测试环境，先不管。

接下来看第二步了，所要做的事情就是把 WndProc 下的 一堆 case 有效地组织起来，或者换个写法。之前还真不知道 MFC/WTL 的 BEGIN_MSG_MAP。以为很高深的，想不到就是拼装成一个大的 WndProc。先抄了，做成一个可运行的版本。但是，这方面会直接决定以后的大部分使用方式，单单抄一下意义不大。后来去 @OwnWaterloo 曾推荐过的 @cexer 的博客上逛了几圈，第一圈看了一些描述性文字，第二圈大概看了下技术，第三圈是挖坟，那个传说中的 cppblog 第一高楼啊。。其中有一个使用方式很新颖，嗯……是那个不需要手动写映射代码，直接实现消息处理函数的方式。不过我后来觉得还是不要这种样子了，凭我个人的直觉，如果我写下这样的处理函数，我大概会因为不知道何时注册了这个函数而找不到调用来源而感到郁闷。在Windows回调机制的影响下，我可能会很抱有偏见地认为，只有直接来自WndProc的调用，才算是来源明确的，不需要继续追踪的——当然，这是建立在我不熟悉这个框架的基础上的。框架必然需要隐藏调用来源，以及其他一些细节，但是在这一步，我觉得稍微有点早。

刚才说到的都是静态绑定。现在我有点倾向于动态绑定。从使用方便程度上来看，动态绑定更具灵活性。从性能上，动态绑定下，消息到处理函数的查找过程可以更快，静态绑定只能遍历。当然，未必将“添加处理函数”这样的接口提供给最终用户，但是这个操作对于整个控件体系的形成应该蛮有帮助的吧。比如MFC下一个控件类使用Message Map做了一些事情，继承类就无法直接继承这个动作，于是可能需要做两套处理函数调用机制，一套是给内部继承用的，一套是给用户的。如果在最开始的基类保存一个消息映射，每个消息对应一族处理函数，每个继承类都可以添加处理函数，但不删除父类已添加的函数，这样就可以在一套Message Map机制下获得父类的行为。以上，不知道考虑得对不对，欢迎讨论。

其中，父类保存子类给出的可调用体并正确执行是个问题。折腾了一些时间，都没有成功。我比较纠结，想知道除了用function之类的玩意儿外还有没有其他简单可行的办法。后来去@zblc的群上问，@vczh也说需要一套function机制。看来是逃不开这个问题了。嗯……想起来大约两个月前一个同事从codeproject找来了一个GUI框架看，看到几行整整齐齐的 AddMsgHandler(WM_CREATE, XXX(this, &MyWindow::OnCreate));，叹不已。我当时打趣说，这很简单的，无非是搞了个 function 而已，哥哥两天就能搞定。于是他们叫我两天搞定。我鼓捣了10分钟，搞不定，只好丢一句，真的很简单的，类似boost::function，你去看一下就知道了，哥哥要干活了。

既然现在还是绕不开这个问题，那还是搞一下了，搞好以后就权且当做给他们交作业吧。我会另写一篇文章说说function的事情，这里先略过。现在开始假设这个设施已经造好了。那么，窗口类中大概可以这么定义相关类型：

typedef Function<bool (WPARAM, LPARAM)> MsgHandler;
typedef List<MsgHandler> MsgHandlerList;
typedef Map<UINT, MsgHandlerList> MsgMap;

然后再定义一个变量：

MsgMap  m_MsgMap;

它用于保存消息映射。最终的回调函数可以写成：

LRESULT WndProc(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    bool bHandled = false;

    MsgMap::Iterator itMsgMap = m_MsgMap.Find(uMsg);

    if (itMsgMap != m_MsgMap.End())
    {
        for (MsgHandlerList::Iterator it = itMsgMap->Value.Begin();
             !bHandled && it != itMsgMap->Value.End(); ++it)
        {
            bHandled = (*it)(wParam, lParam);
        }
    }

    return bHandled ? TRUE : DefWindowProc(m_hWnd, uMsg, wParam, lParam);
}

最后给个添加消息映射的接口：

void AppendMsgHandler(UINT uMsg, MsgHandler pMsgHandler)
{
    m_MsgMap[uMsg].PushBack(pMsgHandler);
}

到目前为止，我们的窗口类大致上可以写成这样：

#include <Windows.h>
#include <tchar.h>
#include "../GUIFramework/xlWindowBase.h"

class Window : public xl::WindowBase
{
public:
    Window()
    {
        AppendMsgHandler(WM_ERASEBKGND, MsgHandler(this, &Window::OnEraseBackground));
        AppendMsgHandler(WM_PAINT,      MsgHandler(this, &Window::OnPaint));
        AppendMsgHandler(WM_LBUTTONUP,  MsgHandler(this, &Window::OnLButtonUp));
        AppendMsgHandler(WM_RBUTTONUP,  MsgHandler(this, &Window::OnRButtonUp));
        AppendMsgHandler(WM_DESTROY,    MsgHandler(this, &Window::OnDestroy));
    }

protected:
    bool OnEraseBackground(WPARAM wParam, LPARAM lParam)
    {
        return false;
    }

    bool OnPaint(WPARAM wParam, LPARAM lParam)
    {
        PAINTSTRUCT ps = {};
        BeginPaint(m_hWnd, &ps);

        RECT rect = { 200, 200, 400, 400 };
        DrawText(ps.hdc, _T("Hello, world!"), -1, &rect, DT_CENTER | DT_VCENTER);

        EndPaint(m_hWnd, &ps);
        return false;
    }

    bool OnLButtonUp(WPARAM wParam, LPARAM lParam)
    {
        MessageBox(m_hWnd, _T("LButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
        return false;
    }

    bool OnRButtonUp(WPARAM wParam, LPARAM lParam)
    {
        MessageBox(m_hWnd, _T("RButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
        return false;
    }

    bool OnDestroy(WPARAM wParam, LPARAM lParam)
    {
        PostQuitMessage(0);
        return false;
    }
};

在最基础的 WindowBase 里，搞成这样大概差不是很多了。暂时先看第三步。到目前为止，我所听说过的 GUI 框架都是真正的框架，似乎没有“GUI 库”。为什么一定要以继承某个基类的方式来使用呢？如果像下面这样使用呢？

class Window
{
private:
    xl::WindowBase m_WindowBase;

public:
    Window()
    {
        m_WindowBase.AppendMsgHandler(WM_ERASEBKGND, MsgHandler(this, &Window::OnEraseBackground));
        m_WindowBase.AppendMsgHandler(WM_PAINT,      MsgHandler(this, &Window::OnPaint));
        m_WindowBase.AppendMsgHandler(WM_LBUTTONUP,  MsgHandler(this, &Window::OnLButtonUp));
        m_WindowBase.AppendMsgHandler(WM_RBUTTONUP,  MsgHandler(this, &Window::OnRButtonUp));
        m_WindowBase.AppendMsgHandler(WM_DESTROY,    MsgHandler(this, &Window::OnDestroy));
    }
};

这个问题，不知道各位有没有什么思考？

还有一个问题是，接下去要不要将 WPARAM 和 LPARAM 的含义彻底解析掉，搞成一系列 PaintParam、EraseBackgroundParam、LButtonUpParam、RButtonUpParam，DestroyParam，让使用的时候与原始消息参数彻底隔离呢？

最后一步，虽说是体力活，但这跟最终的应用场合密切相关，需要提供怎么样的功能是一件需要考量的事。

目前走在第二步，所以下面的两个问题思考得不多。求经验，求意见。

问题：
有没有存在一种好的方式，让DLL能够被动态加载，并且能够方便地得到里面的 C++ class 信息？
备选：
1、别想了，老老实实地用吧，还是导出纯C函数= =
2、大胆的导出 class 吧，如果动态加载，自己去拼那些编译后名字吧。。
3、COM 形式？可是，要注册到系统中去，凭空多了系统注册表依赖
4、还有吗？
5、甚至可以抛开DLL，有没有类似的一种方式，可用于二进制代码的模块划分以及闭源的代码重用？

（至于跨平台啥的先不考虑吧，暂定Windows平台下吧）

请不吝指教~

typedef DWORD (WINAPI *PTHREAD_START_ROUTINE)(
    LPVOID lpThreadParameter
    );
typedef PTHREAD_START_ROUTINE LPTHREAD_START_ROUTINE;

这样，当我们实现线程类的时候，就可以：

class Thread
{
private:
    HANDLE m_hThread;

public:
    BOOL Create()
    {
        m_hThread = CreateThread(NULL, 0, StaticThreadProc, (LPVOID)this, 0, NULL);
        return m_hThread != NULL;
    }

private:
    DWORD WINAPI ThreadProc()
    {
        // TODO
        return 0;
    }

private:
    static DWORD WINAPI StaticThreadProc(LPVOID lpThreadParameter)
    {
        ((Thread *)lpThreadParameter)->ThreadProc();
    }
};

不过，这样，成员函数 ThreadProc() 便丧失了一个参数，这通常无伤大雅，任何原本需要从参数传入的信息都可以作为成员变量让 ThreadProc 来读写。如果一定有些什么是非从参数传入不可的，那也可以，一种做法，创建线程的时候传入一个包含 this 指针信息的结构。第二种做法，对该 class 作单例限制——如果现实情况允许的话。

所以，有额外参数的回调函数都好处理。不幸的是，Windows 的窗口回调函数没有这样一个额外参数：

typedef LRESULT (CALLBACK* WNDPROC)(HWND, UINT, WPARAM, LPARAM);

这使得对窗口的 C++ 封装变得困难。为了解决这个问题，一个很自然的想法是，维护一份全局的窗口句柄到窗口类的对应关系，如：

#include <map>

class Window
{
public:
    Window();
    ~Window();
   
public:
    BOOL Create();

protected:
    LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);

protected:
    HWND m_hWnd;

protected:
    static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
    static std::map<HWND, Window *> m_sWindows;
};

在 Create 的时候，指定 StaticWndProc 为窗口回调函数，并将 hWnd 与 this 存入 m_sWindows：

BOOL Window::Create()
{
    LPCTSTR lpszClassName = _T("ClassName");
    HINSTANCE hInstance = GetModuleHandle(NULL);

    WNDCLASSEX wcex    = { sizeof(WNDCLASSEX) };
    wcex.lpfnWndProc   = StaticWndProc;
    wcex.hInstance     = hInstance;
    wcex.lpszClassName = lpszClassName;

    RegisterClassEx(&wcex);

    m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

    if (m_hWnd == NULL)
    {
        return FALSE;
    }

    m_sWindows.insert(std::make_pair(m_hWnd, this));

    ShowWindow(m_hWnd, SW_SHOW);
    UpdateWindow(m_hWnd);

    return TRUE;
}

在 StaticWindowProc 中，由 hWnd 找到 this，然后转发给成员函数：

LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    std::map<HWND, Window *>::iterator it = m_sWindows.find(hWnd);
    assert(it != m_sWindows.end() && it->second != NULL);

    return it->second->WndProc(message, wParam, lParam);
}

（m_sWindows 的多线程保护略过，下同）

据说 MFC 采用的就是类似的做法。缺点是，每次 StaticWndProc 都要从 m_sWindows 中去找 this。由于窗口类一般会保存窗口句柄，回调函数里的 hWnd 就没多大作用了，如果这个 hWnd 能够被用来存 this 指针就好了，那么就能写成这样：

LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}

这样看上去就爽多了。传说中 WTL 所采取的 thunk 技术就是这么干的。之前，只是听过这遥远的传说，今天，终于有机会走进这个传说去看一看。参考资料是一篇不知原始出处的文章《深入剖析WTL—WTL框架窗口分析》，以及部分 WTL 8.0 代码，还有其他乱七八糟的文章。

WTL 的思路是，每次在系统调用 WndProc 的时候，让它鬼使神差地先走到我们的另一处代码，让我们有机会修改堆栈中的 hWnd。这处代码可能是类似这样的：

__asm
{
    mov dword ptr [esp+4], pThis  ;调用 WndProc 时，堆栈结构为：RetAddr, hWnd, message, wParam, lParam, ... 故 [esp+4]
    jmp WndProc
}

由于 pThis 和 WndProc 需要被事先修改（但又无法在编译前定好），所以我们需要运行的时候去修改这部分代码。先弄一个小程序探测下这两行语句的机器码：

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    return 0;
}

int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{
    MessageBox(NULL, NULL, NULL, MB_OK);

    __asm
    {
        mov dword ptr [esp+4], 1
        jmp WndProc
    }

    return 0;
}

最前面的 MessageBox 是为了等下调试的时候容易找到进入点。

然后使用 OllyDbg，在 MessageBoxW 上设置断点，执行到该函数返回：

这里我们看到，mov dword ptr [esp+4] 的机器码为 C7 44 24 04，后面紧接着的一个 DWORD 是 mov 的第二个操作数。jmp 的机器码是 e9，后面紧接着的一个 DWORD 是跳转的相对地址。其中 00061000h - 0006102Bh = FFFFFFD5h。

于是定义这样一个结构：

#pragma pack(push,1)
typedef struct _StdCallThunk
{
    DWORD   m_mov;          // = 0x042444C7
    DWORD   m_this;         // = this
    BYTE    m_jmp;          // = 0xe9
    DWORD   m_relproc;      // = relative distance
} StdCallThunk;
#pragma pack(pop)

这个结构可以作为窗口类的成员变量存在。我们的窗口类现在变成了这样子：

class Window
{
public:
    Window();
    ~Window();

public:
    BOOL Create();

protected:
    LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);

protected:
    HWND         m_hWnd;
    StdCallThunk m_thunk;

protected:
    static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
};

似乎少了点什么……创建窗口的时候，我们是不能直接把回调函数设到 StaticWndPorc 中去的，因为这个函数是希望被写成这样子的：

LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}

那么至少需要一个临时的回调函数，在这个函数里去设置新的回调函数（设到 m_thunk 上），再由 m_thunk 来调用 StaticWndProc，StaticWndProc 再去调用 WndProc，这样整个过程就通了。

但是，临时回调函数还是需要知道从 hWnd 到 this 的对应关系。可是现在我们不能照搬用刚才的 m_sWindows 了。因为窗口在创建过程中就会调用到回调函数，需要使用到 m_sWindows 里的 this，而窗口被成功创建之前，我们没法提前拿到 HWND 存入 m_sWindows。现在，换个方法，存当前线程 ID 与 this 的对应关系。这样，这个类变成了：

#include <map>

class Window
{
public:
    Window();
    ~Window();

public:
    BOOL Create();

protected:
    LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);

protected:
    HWND         m_hWnd;
    StdCallThunk m_thunk;

protected:
    static LRESULT CALLBACK TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);

然后实现 Create 和 TempWndProc：

BOOL Window::Create()
{
    LPCTSTR lpszClassName = _T("ClassName");
    HINSTANCE hInstance = GetModuleHandle(NULL);

    WNDCLASSEX wcex    = { sizeof(WNDCLASSEX) };
    wcex.lpfnWndProc   = TempWndProc;
    wcex.hInstance     = hInstance;
    wcex.lpszClassName = lpszClassName;

    RegisterClassEx(&wcex);

    DWORD dwThreadId = GetCurrentThreadId();
    m_sWindows.insert(std::make_pair(dwThreadId, this));

    m_thunk.m_mov = 0x042444c7;
    m_thunk.m_jmp = 0xe9;

    m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

    if (m_hWnd == NULL)
    {
        return FALSE;
    }
   
    ShowWindow(m_hWnd, SW_SHOW);
    UpdateWindow(m_hWnd);

    return TRUE;
}

LRESULT CALLBACK Window::TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    std::map<DWORD, Window *>::iterator it = m_sWindows.find(GetCurrentThreadId());
    assert(it != m_sWindows.end() && it->second != NULL);

    Window *pThis = it->second;
    m_sWindows.erase(it);

    WNDPROC pWndProc = (WNDPROC)&pThis->m_thunk;

    pThis->m_thunk.m_this = (DWORD)pThis;
    pThis->m_thunk.m_relproc = (DWORD)&Window::StaticWndProc - ((DWORD)&pThis->m_thunk + sizeof(StdCallThunk));

    m_hWnd = hWnd;
    SetWindowLong(hWnd, GWL_WNDPROC, (LONG)pWndProc);

    return pWndProc(hWnd, message, wParam, lParam);
}

差不多可以了，调试一下。结果，在 thunk 的第一行出错了。我原以为地址算错了神马的，尝试把 thunk.m_mov 改为 0x90909090，再运行，还是出错。于是傻掉了……过了好一会儿才意识到，可能是因为 thunk 在数据段，无法被执行。可是，很久很久以前偶滴一个敬爱的老师在 TC 中鼓捣程序运行时改变自身代码时，貌似无此问题啊。。。然后查呀查，原来是 Windows 在的数据执行保护搞的鬼。于是，需要用 VirtualAlloc 来申请一段有执行权限的内存。WTL 里面也是这么做的，不过它似乎维护了一块较大的可执行内存区作为 thunk 内存池，我们这里从简。最后，整个流程终于跑通了。最终代码清单如下：

#pragma pack(push,1)
typedef struct _StdCallThunk
{
    DWORD   m_mov;
    DWORD   m_this;
    BYTE    m_jmp;
    DWORD   m_relproc;

} StdCallThunk;
#pragma pack(pop)

class Window
{
public:
    Window();
    ~Window();

public:
    BOOL Create();

protected:
    LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);

protected:
    HWND          m_hWnd;
    StdCallThunk *m_pThunk;

protected:
    static LRESULT CALLBACK TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
    static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
    static std::map<DWORD, Window *> m_sWindows;
};

std::map<DWORD, Window *> Window::m_sWindows;

Window::Window()
{

}

Window::~Window()
{
    VirtualFree(m_pThunk, sizeof(StdCallThunk), MEM_RELEASE);
}

BOOL Window::Create()
{
    LPCTSTR lpszClassName = _T("ClassName");
    HINSTANCE hInstance = GetModuleHandle(NULL);

    WNDCLASSEX wcex    = { sizeof(WNDCLASSEX) };
    wcex.lpfnWndProc   = TempWndProc;
    wcex.hInstance     = hInstance;
    wcex.lpszClassName = lpszClassName;
    wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);

    RegisterClassEx(&wcex);

    DWORD dwThreadId = GetCurrentThreadId();
    m_sWindows.insert(std::make_pair(dwThreadId, this));

    m_pThunk = (StdCallThunk *)VirtualAlloc(NULL, sizeof(StdCallThunk), MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    m_pThunk->m_mov = 0x042444c7;
    m_pThunk->m_jmp = 0xe9;

    m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

    if (m_hWnd == NULL)
    {
        return FALSE;
    }
   
    ShowWindow(m_hWnd, SW_SHOW);
    UpdateWindow(m_hWnd);

    return TRUE;
}

LRESULT Window::WndProc(UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_LBUTTONUP:
        MessageBox(m_hWnd, _T("LButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
        break;
    case WM_RBUTTONUP:
        MessageBox(m_hWnd, _T("RButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        break;
    }

    return DefWindowProc(m_hWnd, message, wParam, lParam);
}

LRESULT CALLBACK Window::TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    std::map<DWORD, Window *>::iterator it = m_sWindows.find(GetCurrentThreadId());
    assert(it != m_sWindows.end() && it->second != NULL);

    Window *pThis = it->second;
    m_sWindows.erase(it);

    WNDPROC pWndProc = (WNDPROC)pThis->m_pThunk;

    pThis->m_pThunk->m_this = (DWORD)pThis;
    pThis->m_pThunk->m_relproc = (DWORD)&Window::StaticWndProc - ((DWORD)pThis->m_pThunk + sizeof(StdCallThunk));

    pThis->m_hWnd = hWnd;
    SetWindowLong(hWnd, GWL_WNDPROC, (LONG)pWndProc);

    return pWndProc(hWnd, message, wParam, lParam);
}

LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}

int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{
    Window wnd;
    wnd.Create();

    MSG msg;

    while (GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return (int)msg.wParam;
}

刚才有一处，存 this 指针的时候，我很武断地把它与当前线程 ID 关联起来了，其实这正是 WTL 本身的做法。它用 CAtlWinModule::AddCreateWndData 存的 this，最终会把当前线程 ID 和 this 作关联。我是这么理解的吧，同一线程不可能同时有两处在调用 CreateWindow，所以这样取回来的 this 是可靠的。

好了，到此为止，边试验边记录的，不知道理解是否正确。欢迎指出不当之处，也欢迎提出相关的问题来考我，欢迎介绍有关此问题的新方法、新思路，等等，总之，请各位看官多指教哈。

前两天终于有可以随时操作的且重现几率非常高的机器了，测试了一下，发现一个规律：只要在调用 InternetOpenURL 之前调用过 SHGetFolderPath，此问题的重现几率就非常高；如果没有调用过 SHGetFolderPath，则基本不出现。

目前网上找到的一个几乎唯一的帖子是 http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/2982efc6-8403-4577-9dba-ad5cfdf01753，现象几乎一模一样。只可惜没有有价值的回复。该文章的作者指出的 VPN 等网络原因好像不是关键，在我这里是很普通的局域网，一样能出现。

测试代码如下：

#include <Windows.h>
#include <tchar.h>
#include <ShlObj.h>

#include <WinInet.h>
#pragma comment(lib, "wininet.lib")

#define URL _T("http://www.baidu.com/")

int main()
{
    TCHAR szCommonAppData[MAX_PATH];
    SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, SHGFP_TYPE_CURRENT, szCommonAppData);

    HINTERNET hInternet = InternetOpen(_T("WCU"), INTERNET_OPEN_TYPE_PRECONFIG_WITH_NO_AUTOPROXY, NULL, NULL, 0);

    if (hInternet == NULL)
    {
        return 0;
    }

    HINTERNET hInternetFile = InternetOpenUrl(hInternet, URL, NULL, 0, INTERNET_FLAG_NO_UI | INTERNET_FLAG_RELOAD, 0);

    if (hInternetFile == NULL)
    {
        InternetCloseHandle(hInternet);
        return 0;
    }

    InternetCloseHandle(hInternetFile);
    InternetCloseHandle(hInternet);

    return 0;
}

在能够出现此问题的机器上，Ctrl + F5 直接运行，几乎每次必现；如果 F5 调试运行，则几率小一点，但是跑个七八次左右基本上能出现。目前 XP 32/64 上都有发现这个问题，Vista/Win7 上暂时没有发生此现象。（如果 InternetOpenURL 换成 InternetConnect、HttpOpenRequest、HttpSendrequest，则会 crash 在 HttpSendRequest 内。）

附件是一个测试工程，附带上了 Debug、Release 版本的 EXE、PDB 文件以及 Crash 时的 Dump 文件。请有心人帮忙看看。^_^
点击下载

可是，如果这个问题确实存在，为什么网上查到的相关内容这么少呢？奇怪~

好讨厌，ri啊ri。。。

各位有没有突破方法：找到一个任何用户都可以可靠读写的位置？

小记一笔。明天继续看 64 位的。

==================================================
WinXP x64: 0x158
Vista x64: 0x160
Win7 x64: 0x200

但如果从控制面板=>添加删除程序（程序和功能）里执行（相当于执行 msiexec /…），在过一会儿弹出的 UAC 对话框中选管理员用户，此时 HKEY_CURRENT_USER 为管理员用户的数据，但是 SH… 系列 API 的执行环境却是标准用户。查看两个 MsiExec.exe 进程，其中一个是 System 用户的，也就是 Windows Installer 服务对应的进程；另一个是管理员用户的，但是用 Process Explorer 查看，它的所有环境路径全是标准用户的。

觉得有点奇怪，是以记之。^_^