库本身是Windows的，实际上之前已经移植到linux/macos，跑着也正常。
但是是两份代码，一直偷懒，没统一成一份代码。大概不到2万行。
现在让反重力把它统一成一份代码。我可以用我自己的两份代码做diff来看看它的移植有没遗漏的。

先告知它，需要将这份Windows代码改成支持三个平台的，用cmake + vcpkg管理，并且封装哪几个函数给Rust调用，并写一个Rust测试程序来测试接口。

它扫了一遍代码，很快总结出哪些地方是跟可移植性相关的，自动把这些抽取出来放到一个新文件portability.h里，
自动为一些Windows特有的特性生成linux/macos上的模拟代码，比如IStream、CComPtr、操作VARIANT的API函数等。
然后它建立了一个cmake工程，写Rust wrapper接口和测试程序。
之后先在Windows上，它自动根据编译器的报错，逐步修改，编译通过，测试程序跑正确。

然后在linux和macos上再搭建反重力的环境，编译、测试。最后还要手动单步调试定位一个编码转换问题。

由于移植工作代码量小，我没写一行代码，建立工程、编译、写commit message并提交代码，都是让它搞的，我只是做提示。
提交代码时发现ssh证书有问题，它是知道在ssh -T命令后面加-vvv参数来看调试信息的，最后发现是因为ssh程序有两份拷贝导致的。
我告知测试程序输出的字符串有乱码时，它知道在对应的代码位置加上十六进制的日志代码来分析编码转换问题。

也有几处有点问题，靠测试发现的。举例：
1、模拟Windows的IStream::Stat()，最开始生成的是一个空函数，直接返回E_NOTIMPL，它把怎么实现给放到注释里了。
2、linux/macos上给std::ifstream传递的是std::wstring类型的文件名，我告知不对后，它又改成传递std::filesystem::path(std::wstring)，还是不对。只好强行指定其要转UTF8。
3、用libiconv将utf8转为std::wstring时，它用的iconv("WCHAR_T", "UTF-8")。这个"WCHAR_T"在macos上是big-endian的（这是C ABI的规定，跟CPU的endian无关），而我原来的代码是没遵守这个C ABI，从而导致错误。要手动改为"UTF-32LE"，将错就错就行。
--
FROM 61.51.229.*