花有重开日，人无再少年。可任谁也没想到，二十年后，TWL 还能借助最新的技术进展，在 AI 的帮助下完善、增强。
先是把 64 位支持的缺陷（当时还不太急迫，所以只是个缺点；而现在显然就是缺陷了）补上，又把之前一些零星散落在各个测试工程里的有用的控件（如 TreeList）、组件（如 Caption Button、Menu Pin）、功能函数（如 Docking 能力、msimg32 软实现等）、代码片段做了一些整合，融入到 TWL 的整体中来。
当基本上告一段落时，三太爷又想尝试一下看能否把一个现成的 SDK 或者 MFC 程序迁移到 TWL 上来，以便观察整体的难度，以及考察 TWL 本身的完整性和适应性。思来想去，选了一个奇怪的目标：Windows 系统中期里的画笔程序。
先是到 GitHub 上找到了之前微软泄漏出来的源代码树：
- Windows NT 4：https://github.com/ZoloZiak/WinNT4；
- Windows 2000：https://github.com/gameprive/win2k；
- Windows XP：https://github.com/ufwt/windows-XP-SP1；
- Windows Server 2003：https://github.com/selfrender/Windows-Server-2003。
Windows NT 4 的代码里没有画笔的部分，显然是上传的人没有完整上传（因为根据之前的印象，应用层的很多代码在那次的泄露内容中是有的）。既然如此，那就到 Windows 2000 里去找，GitHub 的项目内查找做得快如闪电，一击命中，位置在 private/windows/shell/accesory/mspaint 下，同时为了证实，也去 Windows XP 的那个仓库里看了一眼，也有，XPSP1/NT/shell/osshell/accesory/mspaint。
都取下来，出于好奇还比较了一下，发现相差无几。让反重力出个迁移至 TWL 的方案，它的结论有模有样，建议为了不至于对整个项目的代码大肆翻腾，除了把缺的一些边角自动补齐外，建议做一个 MFC 到 TWL 的“垫层”来对接画笔现有代码和 TWL。甚有工程思维，准了。
原以为它语气笃定、轻描淡写就出来的方案会很容易，实在没想到它吭哧憋肚出来的第一个可以运行的版本用时竟然在小时这个量级上。跑起来的时候我觉得这一定就是 TWL 的版本了，更没成想反重力说的是：现在咱们把第一阶段要补的都补齐了，下一个阶段计划把 OLE 服务器的特性去除掉，然后再对接 TWL 怎么样？还能怎么样，当然是你说怎样就怎样了。剥离 OLE 特性好像用时不多，接下来就是老夫在体验 AI 这么长的时间里遇到的第一个比较漫长的单一任务了：它来来回回调整一个叫 twlmfc.h 的头文件，直至最终构建出 TWL 版的画笔程序来，耗时六个半小时。其后又花了大概略逊但接近的时间，把我体验过程中发现的共计十个 bug 修复了。TWL 版的画笔初步落成。
整个过程中没有提出 TWL 需要调整的建议，而耗时较长的主要原因在于，TWL 没有对 MFC 里非常重头的文档-视图结构进行支持。总的来说，结果还不错。
刚刚在 GitHub 的搜索结果里多翻了几页，还有几个仓库：
- https://github.com/Hengle/windows_nt_3_5_source_code；
- https://github.com/lianthony/NT4.0；
- https://github.com/tongzx/nt5src；
- https://github.com/Hengle/windows_2000_source_code。
也许跟更上面的一样，聊做备份。