由于需要使用虚拟主机的 PHP 8，之前的 WordPress 5.4 已经无法支持了，所以花了点时间将博客更新到 WordPress 6.9。为了使用新版 WordPress，虚拟主机搭配的 MySQL 5.1 也需要升级到服务商能提供的最高 MySQL 5.7，导入数据时还出现了一些波折，服务商提供的导入导出工具无法正确导入，最后靠老版本的 MySQL Workbench 完成了数据库的迁移。WordPress 更新比较简单，先在 PHP 7 环境下，按照官方手册进行升级。
https://developer.wordpress.org/advanced-administration/upgrade/upgrading/#manual-upgrade
完成升级后，把虚拟主机环境升级到 PHP 8.4，就完成了。
新 Bing 默认背景 4K 原版
New Bing default background 4K original
直接下载链接 Download link: https://www.sunjw.us/blog/wp-content/uploads/2023/02/OHR.CodexMountains_EN-US2295216929_UHD.jpg
做了一个简单的二维码生成器，可以输入任何文字立即生成二维码。
I released a QR code generator, input text and get QR code, very simple.
好久没有更新博客了，最近有点时间干脆把 WordPress 本身更新一下，其实过程挺简单的，唯一的问题是 WordPress 的自动升级似乎不起作用。既然不能自动更新，那么就根据以下两个链接的手动升级过程就成功了：
现在你看到的就是 WordPress 5.4 的新版博客了。
Windows 10 1903（build 18282）新默认壁纸 4K 原版
Windows 10 1903 (build 18282) new default wallpaper 4K original version
直接下载链接（dowload link）：https://www.sunjw.us/blog/wp-content/uploads/2018/11/img0_3840x2160.jpg
工作之后好久不写博客了，这里都要长草了。。。
之前写过一篇 Build CyanogenMod 10.2 for Nexus 4，现在手机换成 Nexus 5 了，系统也升级到 CM 12 了，写一篇 How to 总结一下。
1. 你还是要准备一台机器（虚拟机也行），装上 Ubuntu，Ubuntu 14 LTS 是个不错的选择，LTS 会有很长时间的软件更新支持。硬盘分的大一些，100GB 起步吧，内存 3G 起，其他随意。
前段时间，在用 npp 分析一个 html 文件时，准备把其中的混合在一起的 js 分离出来，在 js 前后换行时 npp 崩溃了，感觉是哪里 bug 了，重试了几次都能很稳定的重现。本着张银奎老师的精神，上调试器。用 windbg 附加到 npp 进程，重现这个 crash 后，停到调试器内，看了下栈。
很明显栈溢出了，返回地址都是文本中的字符，溢出发生在 NotepadSharp.dll 也就是 Notepad# 插件中。Npp 上的插件基本都是开源的，那就把代码搞下来，用 VS 编译了个 debug 版，放进去再次触发崩溃，发现 PluginDefinition.cpp 的 void Newline() 函数中
一直想尝试着自己编译 CM，毕竟如果想修改系统 Apk，就有可能需要编译整个系统。于是在开了一台 Ubuntu x86_64 虚拟机（这是一个大坑，等会儿说）作为编译机器，参考的主要是 CM 官方 wiki：http://wiki.cyanogenmod.org/w/Build_for_mako?setlang=en。根据 wiki 指示准备好基础环境后，开始 repo sync，总共下载了 6GB 多的工程代码。总的来说，一直到 wiki 的 “Start the build” 一节，都没有问题，照着做就好了。不过当执行 brunch mako 之后，坑就一个个冒出来了。
增加 Shell Extension 实现的高级右键菜单支持
修正其他 bug
Use Shell Extension to implement context menu shortcut
Fix other bugs
Download:
https://code.google.com/p/fhash/downloads/list
http://sourceforge.net/projects/fhash/files/1.8/
其实也就是记录一下用 WinDbg 调试 fHash 的一次过程，这个 bug 是由于没好好看文档造成的，我需要让 fHash 知道当前运行的操作系统是 32 位还是 64 位的，之后好去选择正确的 shell extension 文件。查文档看到了这个函数 IsWow64Process ，之后错误的以为 kernel32 中有这个函数就是 64 位操作系统，结果就已这个逻辑写下了错误的 64 位系统判断函数，和错误文件读取逻辑。
tstring tstrExeDirPath(pszExeFullPath);
tstring::size_type idx = tstrExeDirPath.rfind(_T("\\"));
tstrExeDirPath = tstrExeDirPath.substr(0, idx);
tstring tstrShlExtDll = tstrExeDirPath;
tstrShlExtDll.append(_T("\\fHashShlExt"));
if(IsWindows64())
tstrShlExtDll.append(_T("64"));
tstrShlExtDll.append(_T(".dll"));
WIN32_FIND_DATA ffData;
HANDLE hFind = FindFirstFile(tstrShlExtDll.c_str(), &ffData);
bool bRet = (hFind != INVALID_HANDLE_VALUE);
if(bRet)
{
#if defined(UNICODE) || defined(_UNICODE)
wcscpy_s(pszShlDllPath, MAX_PATH, tstrShlExtDll.c_str());
#else
strcpy_s(pszShlDllPath, MAX_PATH, tstrShlExtDll.c_str());
#endif
FindClose(hFind);
}
return bRet;
结果很自然，在 32 位的 Windows XP 上没有执行正确。但是测试环境没有 VisualStudio，而且用的是 Release 编译，也没有带着符号文件，这怎么调试呢。Windows XP 上装有 WinDbg，那么就用它来调试。