59 个库，50 个能在 Linux 跑

# 59 个库，50 个能在 Linux 跑

## 库是 Fun 自己写的，所以移植很便宜

Fun 的标准库（上游 README 记的是 59 个模块，约 6000 行逻辑代码）全部用 Fun 自身写成。Pascal 宿主只负责解释器、解析器和少数几个内建函数。

这个「自托管」的选择在移植时兑现了价值：解释器核心一旦在 Linux 上跑起来，纯逻辑的库一行都不用改。需要动手的，只有那些直接调 Windows API、或通过 `getapi()` 载入 DLL 的模块。

按 commit `1e910a1`（v9.1）的代码逐个核对，59 个模块分成四类：

| 分类 | 数量 | 占比 | 说明 |
| --- | --- | --- | --- |
| A · 直接可用 | 28 | 47.5% | 纯 Fun，不碰系统 API |
| B · 已换后端 | 22 | 37.3% | 运行时探测 os，走 `-lnx` / `-base` 后端 |
| C · 待移植 | 2 | 3.4% | 有等价物，还没做 |
| D · 建议放弃 | 7 | 11.9% | 依赖的抽象在 Linux 上没有对应物 |

作者的 `loadcheck` 验证是 **50/59**，和这份分类（A 加 B 正好 50）对得上。

## A 类：28 个纯 Fun 模块

只要不调 Windows API、不用 `getapi` 载 DLL，跨平台就是免费的。这批里有 JSON、YAML、Base64、set/tree/stack、数学与字符串扩展、FD 与 BNF、C 结构体打包解包：

```text
lib-json  lib-yaml  lib-base64  lib-set  lib-tree  lib-stack
lib-math  lib-string  lib-regex  lib-match  lib-file  lib-time
lib-fd  lib-bnf  lib-cstruct  lib-eval  lib-stream  lib-type  ...
```

有两个细节值得注意：`lib-regex` 是纯 Fun，它依赖的是解释器内建的正则运算符，不是 PCRE；`lib-cstruct` 只用了已经跨平台的 `charSize()`。

## B 类：22 个换了后端

这批是这轮移植的主体。作者用了三种分发模式，模块越复杂，拆得越开。

**模式一：单文件内部分支。** 差异小的模块，加载时探测一次 os，一个文件里用 if 分支：

```fun
var _asm_linux = 'host'.arg().getJson(fd: true).os = 'linux';
```

代表是 `lib-asm`：Windows 端 `VirtualAlloc` 加 `C2 ret`（stdcall），Linux 端 `mmap` 加 `C3 ret`（SysV）。`lib-zlib` 也是这一类：`z_stream` 结构体在 Win64 是 56 字节，在 LP64 下是 112 字节，布局得跟着变。

**模式二：双后端文件。** API 模型差异大的模块，`lib-X.fun` 保持 Windows 实现，另写一个 `lib-X-lnx.fun`。`lib-os`、`lib-crypt`、`lib-proc`、`lib-unicode`、`lib-cmdline`、`lib-jsonrpc`、`lib-orm-rpc` 都是这样。

**模式三：三件套。** 有共享逻辑的模块，把平台中立的部分抽到 `lib-X-base.fun`：

```text
lib-winsock-base.fun (542 行) + lib-winsock.fun (319 行) + lib-winsock-lnx.fun (629 行)
```

协议层只写一次，两个后端各实现 6 个 socket hook。

## 调用方怎么选：一个 FD 字符串

所有分发都建立在同一个内建函数上，`'host'.arg()` 返回一段 FD 文本：

```text
fun "9.0"
os linux
cpu x86_64
compiler fpc 3.2.2
bits 64
chars 1
```

编译期常量，零开销，可以 `getJson` 也可以直接正则匹配。于是调用方（或模块内部）就一行判断：

```fun
if 'host'.arg().getJson(fd: true).os = 'linux' then
  use 'lib-X-lnx.fun' as libX;
else
  use 'lib-X.fun' as libX;
end if;
```

老脚本一个字不用改。

## 样板：lib-winsock 把「异步」降成「调度」

这轮移植里最值得看的是 lib-winsock 的三件套。Windows 端靠 `WSAAsyncSelect` 加消息泵，Linux 端既没有消息泵，也没有另起 pthread，而是用 `poll(2)` 的超时参数把异步降维成调度：

```fun
class Scheduler()
  fun Post(fx)      # 立即
  fun After(ms, fx) # 延迟
  fun Every(ms, fx) # 周期
  fun NextIn()      # 下一个 timer 还有多久
  fun Tick()        # 处理到期 timer
```

事件循环把最近的 timer 折进 poll 超时，一次 poll 醒来后先跑 timer、再处理事件。**整个服务器跑在调用线程上**，因此没有重入问题——Fun 的按函数变量栈本来就不是为跨线程重入设计的。

## 几处能看出取舍的移植

- **lib-xml-lnx 用 libxml2 的 pull API**，不用 DOM。`xmlTextReader` 是一串函数调用，不依赖 `xmlNode` 的结构布局，ABI 更稳；编码、实体、CDATA、命名空间都免费拿到。`toJson()` 严格复刻 Windows 端的输出形状，让上层 `lib-orm` 感觉不到换了实现。
- **lib-ado-lnx 选了 SQLite**，不是 libpq/libmysql。理由和 Fun 的定位一致：嵌入式、无服务端。ADO 的对外契约（`quotes`/`ps`/`OpenSchema`/`Execute`）保持不变，`OpenSchema` 用 `sqlite_master` 加 `PRAGMA table_info` 模拟，所以 `lib-orm`、`lib-orm-pro`、`lib-ado-schema` 全都不用动。
- **lib-ajax-lnx 用 libcurl**。`curl_easy_setopt` 是变参函数，作者按参数类型声明了三次；System V ABI 下 string/long/pointer/callback 走同一组寄存器，这样够用。一个诚实的差异：传输是同步的，`async` 标志接受但不兑现。
- **lib-os 不直接移植**，另起一个 165 行的 `lib-os-lnx.fun` 当「最小可行子集」。12 个纯 Windows 的函数调用即抛清晰的错误，而不是假装成功。
- **lffi 运行时探测 libffi 版本**。`FFI_UNIX64` 在 libffi 3.4 及以上从 1 变成了 2；作者写了 `cifABI`，先试 2、再试 1，让 CentOS 7 和现代发行版共用同一个二进制。

## 剩下的：2 个待移植，7 个放弃

C 类只剩两个，都是低优先级：

- `lib-icmp`：`IcmpSendEcho` 换成 `SOCK_RAW + IPPROTO_ICMP`，技术上可行，但要 root 或 `CAP_NET_RAW`，使用场景受限。
- `lib-jsasync`：`lib-ajax` 已经解决，剩下的依赖是 `lib-ui`；可以照 lib-winsock-lnx 的 Scheduler 重写成无线程版本。

D 类的 7 个建议不移植，因为依赖的抽象层在 Linux 上没有对应物：

| 模块 | 依赖 | 结论 |
| --- | --- | --- |
| `lib-ui` / `lib-ui-base` | KOL 加 IE/Trident 嵌入 | 重写等于新项目（LCL/Qt 加 WebKitGTK） |
| `lib-dialog` | user32 消息框 | 可用 zenity/kdialog 子进程重做 |
| `lib-trayicon` | shell32 托盘 | Linux 要 StatusNotifierItem（D-Bus） |
| `lib-message` | Win32 消息循环 | 已被 Scheduler 取代 |
| `lib-winole` | COM/IDispatch | COM 无 Linux 等价物 |
| `lib-registry` | 注册表 | 层次数据库模型不匹配，建议另写 JSON/INI 配置 |

顺带一句：`lib-async` 虽然依赖 Win32 消息泵，但**不再是阻断点**——lib-winsock-lnx 的 Scheduler 已经提供了等价的 `Post/After/Every`。

## 还剩多少活

按这份核对，解释器与基础、FFI 与机器码、系统与网络层、JSON-RPC、内核加固这几段都已完成或大部分完成，剩下的就是上面那两个 C 类模块，合计大约两周。

## 结语

这份清单真正说明的不是「Linux 支持得不错」，而是自托管的标准库让平台移植的边界变得很清楚：纯逻辑的部分天然跨平台，成本全集中在那些和操作系统直接对话的模块上。边界画出来之后，剩下的工作就只是一个个勾掉——7 个明确不勾，2 个待定，其余 50 个已经在 Linux 上跑起来了。