库本身是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.*

取决于经验和进度要求

有经验的、前期不是很赶进度的，可以从一开始就考虑可移植的写法、用可移植的库，后面基本上不费什么事。

反之就是先用特定于某个OS的库/API先莽一个出来再说，再考虑后面的移植需求

还有个话语权问题，就是话事的人支不支持从一开始就考虑代码和库的跨平台问题（还扯不到架构上去）。
我这个就是我去给别人打工，适配别人（linux/macos），那就要听别人的。
而且话事的人自己也有经验问题，也要考虑项目进度。

所以跨平台用一套代码，通常是在后期重构时来满足。有的产品或者项目可能都活不到这个阶段。

现在是我自己决定用Rust搞跨平台，我就封一套统一的，给Rust用

C++的跨平台主要就是data type、char encoding、file i/o、特定的OS API，这4个里面，前三个现在也都比较容易了。

data type：用定宽的uint8_t/uint16_t那一套
char encoding：用libiconv、ICU
file i/o：用std::filesystem、iostream、POSIX file api，实在满足不了要求就自己wrap一下OS file/filemapping API。
网络：早就有了
IPC：我这个不涉及

【 在 tgfbeta 的大作中提到: 】
: C++的移植相对好整吧
--
修改:z16166 FROM 61.51.229.*
FROM 61.51.229.*

狗是骂人，苟好点。。。

【 在 ESPRADE 的大作中提到: 】
: 所以人类程序员就靠这个现状还能再狗个几年咯…
--
FROM 61.51.229.*