一个模块，两份后端

# 一个模块，两份后端

一句话总结: 把 Fun 标准库移植到 Linux,第一版图省事,把两套实现塞进同一个文件、用 `if _osLinux` 分开。结果是文件越读越乱,改动一处要同时照看两个平台。后来定下一条拆分惯例:Windows 实现保留原模块名,Linux 后端叫 `<name>-lnx.fun`,两边共用的逻辑放进 `<name>-base.fun`。本文以 `lib-proc`、`lib-unicode`、`lib-tcc` 为例,看这条惯例怎么落地,也记下移植时挖出来的两个 Fun 语言本身的坑。

## 两套实现挤在一个文件里

第一轮移植最快:在文件里判断 `_osLinux`,是 Linux 就走另一支。

```fun
if _osLinux then
  ...
else
  ...
end if;
```

能跑,但读起来难受:一个窗口函数的 Windows 实现,和 `/proc` 的解析交错在一起;顺手改一处,另一处也得重新看一遍。更现实的问题是,两边共用的代码只能靠肉眼保证同步。

## 一条惯例,三种情况

所以改成按文件拆。惯例本身很短:

- **Windows 实现保留原模块名**。`lib-proc.fun` 还是 `lib-proc.fun`,既有的 `use 'lib-proc.fun'` 一行都不用改,Windows 行为逐字节不变。
- **Linux 后端叫 `<name>-lnx.fun`**。Linux 调用方写 `use 'lib-proc-lnx.fun'`。
- **两边共用、又不含系统调用的逻辑,抽进 `<name>-base.fun`**。它是内部单元,不计入标准库的模块数。

具体怎么拆,要看两边到底有多少可共享的东西。大致分成三种情况。

## 情况一:没有可共享的,就两个独立文件

`lib-proc` 属于这种。Windows 侧靠 kernel32 的进程/内存 API,Linux 侧读 `/proc`,除了返回值的形状几乎没交集。硬抽一个基类只会多一层间接,不如就写两个文件。

于是 `lib-proc.fun` 回到移植前的原样,`use 'lib-os.fun'` 照旧;Linux 侧是新文件 `lib-proc-lnx.fun`,通过 libc 直接读 `/proc`:

```fun
var _dirOpen  = 'libc.so.6'.getapi('opendir',  's:p');
var _dirRead  = 'libc.so.6'.getapi('readdir',  'p:p');
var _readlink = 'libc.so.6'.getapi('readlink', 'spi:i');
var _open     = 'libc.so.6'.getapi('open',     'sii:i');
var _pread    = 'libc.so.6'.getapi('pread',    'ipil:l');
var _strtoull = 'libc.so.6'.getapi('strtoull', 'sii:l');
```

公共 API 两边同名——`proc.ProcList(...)` / `proc.SearchMem(...)`,所以调用方感知不到底下换了一份实现。

这里踩到一个有意思的边界:`/proc/<pid>/maps` 里的地址是 64 位的十六进制,而 Fun 没有 64 位字面量和 64 位算术。解法是让 libc 的 `strtoull` 直接把字符串算成整数:

```fun
var a = _strtoull(m.@(1), 0, 16);
var b = _strtoull(m.@(2), 0, 16);
```

拿回来的 Int64 做减法、比较都没问题,唯一不能用的是**大于 2^31 的字面量**。够用了。

拆开还有个附加好处:`lib-proc.fun` 顶层 `use 'lib-os.fun'`,而那个模块加载时会一口气解析约 40 个 Windows 句柄——在 Linux 上连加载都做不到。现在 Linux 根本不碰这个文件,问题自然消失。

## 情况二:有共享逻辑,就抽一个基类

`lib-unicode` 不一样:字符集嗅探(是不是 UTF-8、是不是 GB2312)、代码页常量、`utf8toGb2312` 的编排流程,两个平台完全一样,只有"字节 ↔ 宽字符"这一步依赖系统。这就是 `<name>-base.fun` 的用武之地。

基类把平台无关的部分收进来,把两个真正依赖系统的方法声明成抽象:

```fun
class UnicodeBase()
  // 抽象:由两个后端各自覆盖
  fun fromBytes(s, cp)
    raise 'UnicodeBase.fromBytes is abstract';
  end fun;

fun toBytes(s, cp)
    raise 'UnicodeBase.toBytes is abstract';
  end fun;

fun utf8toGb2312(s)
    ...
      result = this.fromBytes(s.toStr(), utf8);
      result = this.toBytes(result, gb2312);
    ...
  end fun;
```

这里有一个必须记住的规则:基类里调用自己要被覆盖的方法,得写 `this.fromBytes`,不能省略 `this`。不带限定的调用会绑定到基类里那个抽象方法,而不是子类的覆盖版本。

两个后端由此各归各位:`lib-unicode.fun` 走 Windows 的 kernel32,`lib-unicode-lnx.fun` 是纯 Fun 的 GBK(CP936) 表实现——一张 48KB 的 `gb2312.tbl`(双字节小端,按 `(前导字节-0x81)*191+(尾字节-0x40)` 索引),加一小段 UTF-8 编解码和一个惰性构建的反查表。Linux 上只支持 gb2312 和 utf8 两个代码页,UTF-16/32/7 会明确报错。

## 情况三:只差一个库名,就留在同一个文件

`lib-tcc` 是第三种:TCC 的 C API 全平台一致,唯一区别是动态库叫什么名字。这种没必要拆文件,在加载时问一次宿主平台就行:

```fun
var tccdll = 'libtcc.dll';
if 'host'.arg().getJson(fd: true).os = 'linux' then
  tccdll = 'libtcc.so';
end if;
```

Windows 把 `libtcc.dll` 放在 `fun.exe` 旁边;Linux 侧 `make-linux-x86_64.sh` 从 `src/3rd/tcc` 编出 `libtcc.so`,放在 `funcmd` 旁边,并用 `-rpath $ORIGIN` 让裸库名能被找到——正是"DLL 放在 exe 旁边"的 Linux 对应做法。

连带一件事:Linux 的 FFI 之前不认 Win32 的 `'C'`(cdecl)调用约定标记。SysV ABI 本来就总是 cdecl,所以让 `'C'` 等价于 `'i'` 即可。`lib-tcc` 自己需要它,它同时修好了 `lib-jit` C 路径里那个一直静默返回 0 的回调。

修完这条链,`lib-jit` 的 C 路径在 Linux 上能跑了:

```fun
NewJit('#!C ii:i int sum(int n){ ... }').call(100);   // 5050
```

汇编路径仍只在 Windows 可用(要 kernel32 的 `VirtualAlloc`)。

## 第三方的部分:缺了降级,不会停

移植的另一半是构建。仓库为了体积和许可,不携带第三方源码/二进制:PCRE 8、Tiny C Compiler 0.9.27、Windows 运行期的两个 DLL。缺了不会让构建失败,只会**降级并打印提示**——没 PCRE 就没正则,没 TCC 就没 `libtcc.so`,核心解释器都不受影响。要完整功能,按 README 的说明取一份源码放到 `src/3rd/` 即可;也可以 `PCRE_SRC=` / `TCC_SRC=` 指到别处。

Linux 的构建入口是 `src/prj/fun/make-linux-x86_64.sh`,脚本会自动编译这两个依赖并生成产物。

## 两个 Fun 语言自己的坑

移植不只是写胶水。下面两个坑都是写库时踩出来、又回头改了工作方式的。

**列表字面量里"参数派生的内建调用"会被重复求值时用错索引。**

```fun
# 错:重复调用时,toByte 用的是上一次的索引
result = [s.toByte(i), i];

# 对:先把值算进局部变量
var c = s.toByte(i);
result = [c, i];
```

正确的写法是把内建调用的结果先算进局部变量。`_u8Get` 就是这么改的。

**正则字面量里不能有真正的空格。** `/a b/` 是语法错误,得写 `\s`。而 `/proc/<pid>/maps` 的解析规则,正好撞上这个。

## 结果

拆分之后,Linux 上本地回归 **67/67**,标准库可加载检查 **43/59**(Windows 侧代码全部保持逐字节不变,所有改动都用平台条件或拆文件隔开)。

一句话总结:跨平台不是把两套实现揉进一个文件,而是给它们各留一个文件,再把真正共享的那部分抽出来。约定越简单,两个平台越不容易互相绊倒。