无奖竞猜，这个图标是哪个 AI 做的。
前阵子折腾了好久给 Locale Emulator（LE） 做了下升级，新版名字叫 LocaleEmulatorPlus（简称 LEP），目前已经迭代得比较稳定了，来分享一下。
项目地址（下载直接去 Releases 即可）： https://github.com/julixian/LocaleEmulatorPlus
为什么要重新折腾 LE？
平时推生肉或者玩老游戏的朋友，电脑里基本都装过 LE 或者 LR（Locale Remulator）。
只不过原版 LE 目前已经 archived 了，5 年没有更新。且不说没有 x64 支持（毕竟目前除了 BGI 等少数几个引擎只提供 x64 的 exe，大部分引擎为了兼容性基本还是保持 x86 或是提供 x86 版本的可执行文件，而另一个只提供 x64 版的 AdvHD 还已经全面使用 W 系 API 了根本不需要转区，所以可以暂时忽略这个问题），就连 LE 目前有的一些 bug 想找人修也没处寻了。
至于 LR，虽然说是支持 x64，但实际用下来应该都有体会。那种偏上层用户态的 API Hook 的实现要想实现高质量的转区效果只能说还是太天方夜谭了。毕竟 LR 的作者一开始也不是为了 galgame 这种可能有各种妙妙代码和老古董在的生态而设计的，属于是当时能跑就行。
相比之下，LE 留下的底层技术栈还是很硬核的——它是趁目标进程的 kernel32.dll 甚至都还没加载之前，单靠 ntdll 抢先作为进程里的第一个 DLL 注入进去，赶在系统建立 NLS 区域缓存之前就把代码页、区域、时区、注册表乃至 UI 语言环境全给接管伪造好。只要这套底层能加上 64 位和跨架构支持，转区效果依然是目前最稳的。
LEP 主要升级和修了些什么？
除了保留原版 LE 的右键菜单和配置体验之外，核心主要做了这么几件事：
原生 x86 / x64 双架构支持 + 跨架构传播不管是纯 32 位、纯 64 位，还是「64 位启动器 -> 32 位游戏」「32 位登录器 -> 64 位组件 -> 32 位本体」这种套娃进程链，现在都能自动识别架构并把转区环境一路传下去。
修了些 Galgame 引擎的陈年老 Bug
举几个大家可能遇到过的典型例子：
Lucifen 引擎：修了安装程序在菜单界面点安装会直接卡死无响应的问题；
Strikes 引擎：修了文字演出速度没拉满时，文本排版严重错乱的问题；
椎名理绪（ShiinaRio）：修了部分作品在正常的异常处理流程中莫名其妙在目录里生
.dmp崩溃转储文件的问题；含日区校验的游戏：比如经典的 Siglus 引擎时区校验，现在选东京时区会统一返回标准的『東京標準時』，可以不需要过区域验证的补丁就直接进游戏。还碰到一个老 Triangle 引擎的游戏会检测你默认输入法是不是日文输入法（这真的是人类能想出来的吗，日本人你牛大了），也都支持了。（上述这些情况需要把 UI 语言 Hook 的挡位打到 2）；
其他细节疑难杂症：像
TextOutA单字符输出时的半角日文假名乱码、系统#32770（计算机）弹窗乱码、窗口标题冒问号?、以及更完整的原生 MUI 界面语言模拟，基本都挨个补齐了。
不止步于 Galgame：
本来我做这个分支只是想完善对 Galgame 的支持，但它现在甚至能跑一些我自己都觉得不可思议的东西……
比如在仓库的 issue 里，有在英文版 Windows 系统下玩国服游戏的，拿 LEP 去转区跑 《QQ飞车》端游——还顺便帮我测出了英文宿主系统转中日文时 USER32 双字节模式颠倒、中文输入法打字吞字和剪贴板粘贴的问题（这几个问题在最近版本里也全都修通了，虽然属于是修修补补打补丁式的修复，因为 User32 这个问题比较难从底层处理，它更多是 User32 这个 dll 里的代码逻辑的问题）。
还有人拿去启动带 SkyProtect 反作弊 的网游（《超级跑跑》，启动链路是 x86 启动器 -> x64 反作弊守护进程 -> x86 游戏本体 反复横跳），把跨架构 Broker 的句柄权限传播修好之后，居然也能带着转区跑起来。只能说原版 LE 这套早期注入架构底子确实太能打了，LR 那种纯用户态 Hook 碰上这类场景基本想都不用想。
番外：
最后顺便吐槽下——我曾经一度很奇怪，为什么原版 LE 停更这么多年，却一直没什么人去真正升级它的核心代码。
不过看一眼原版 Core 源码这种想法就烟消云散了：底层设计有多惊艳，代码组织就有多屎山。
倒不是原版作者技术不行（恰恰相反，逆向和系统底层功力极深），但是搞出一个三万行的 ml.h 加上两万行的 ml.cpp，五万行宏与模板齐飞的代码没有任何文档说明还是太变态了。我猜测它当年估计是直接把自己攒的一套超大私人工具库不知道是直接文本拼接还是怎么样反正就是直接塞了进来，不知道是怎么想的。而且为了实现『核心 DLL 绝对不静态依赖 kernel32.dll』的苛刻前提，仓库里还藏着一个手动二进制魔改过的 MSVC link.exe 链接器（专门用来绕过原版链接器硬编码禁止 delay-load 系统核心 DLL 的检查，然后 README 里只给一句请自己去看和原版 linker 有什么区别），外加合并 PE 节区、手搓 ntdll 导入表等一堆奇技淫巧。
说实话，在没有 AI 的年代，正常人类面对这五万行无文档私用库外加魔改编译器，看十分钟基本就道心破碎关掉 IDE 了。
所以我也得承认下：本项目是一个纯正的 Vibe Coding 仓库——从头到尾我本人没有手写过一行代码。
整个开发过程里，我基本只负责定宏观方向、提思路、指挥 AI 去逆向分析底层调用链和排查 Bug，让 AI 一点点把那五万行雷霆 ml.h / ml.cpp 彻底拆解重构成人类能读懂的现代模块化代码，顺便把当年完全缺失的架构原理、ABI 规范以及怎么给新版 MSVC link.exe 打补丁的奇妙编译注意事项全都写成了文档记录下来。能把这么好用的老工具盘活并升到 64 位，真得感谢 AI 时代赋能了（虽然烧 Token 烧得也是真肉疼）。
使用提示 & 反馈
系统环境：支持 Win7 ~ Win11（Win7/8 用户记得先装
.NET Framework 4.8运行时；如果是 Windows on ARM 设备跑 x86 游戏，看一眼仓库主页说明把「禁用混合执行模式」勾上就行）。下载安装：去 GitHub Releases 页面 下最新的压缩包，解压后运行
LEPInstaller.exe注册右键菜单即可，用法和原版 LE 基本无缝衔接。
平时推生肉、啃老汉化补丁，或者有其它奇奇怪怪的跨区需求都可以试试看。如果遇到什么转区失败、乱码或者崩溃的游戏，欢迎直接在论坛留言或者去 GitHub 提 Issue。
有做 Gal 管理器或者类似工具的开发者，也可以考虑增加对 LEP 的支持。
以上的说。
3 条回复