由于我们算是世界上最早一批开始进行WinRT第三方应用开发的团队，我们在代码迁移上被迫走在了世界的前面，这其中就包括了SQLite、ZLib等。
对于开源库的使用，不得赞叹下ZLib的代码优雅程度，纯C，全平台移植没有任何问题，包括刚刚出来的WinRT！
相比之下SQLite的代码就没那么漂亮了，2011年的12月份我差不多有一周的时间是专门在做Win32到WinRT的移植，其中最痛苦的就是SQLite部分，在我看来这个代码实在是比较搓，但是为了赶进度，我还是硬着头皮把事情给搞定了。
随着时间的推移，我们觉得我们有必要更新下我们的SQLite版本，于是下载了最新的稳定代码3.7.10，发现代码还是进行了不少重构，优雅了一点，但是还是一样无法通过WinRT的Application Certification，没办法，我就又准备把之前干过一次的代码移植重来一遍，基本都是写API切换，类似LockFileW改成LockFileEx，CreateFileW改成CreateFile2之类的，这项工作本身没有太大的技术含量，主要就是阅读代码的能力，还有就是要足够细心，剩下的就是体力活了。
在这期间我突然发现自己放了一个错误，疏忽了一件事情：开源参与者的热情及开源代码的更新速度！我还是太容易陷入一个点，就无法自拔，看不到周围的其他方案。
在同事的提醒下，我们发现SQLite WinRT分支其实已经进行了一段时间，我Review下分支上面的代码，基本和我之前的改动是一致的，只是目前还在分支上，没有合入trunk。
这个事情其实去年我专门找过，但当时还没有这样的分支，但是过了3个月后的现在我竟然没有想到： 按照开源项目的效率，这些事情很可能已经在解决或者已经被解决了。
感谢开源代码的贡献者们，期待SQLite 3.7.11
附注：
从代码提交记录看，SQLite官方2012-06-06之后的版本就已经支持WinRT了:代码合入信息