# Wine on OpenHarmony 适配方案
## 1. OpenHarmony 原生适配 Wine 的思路
OpenHarmony 虽然默认使用标准Linux 内核的操作系统，其图形栈、音频栈与常见Linux 桌面环境不同，因此无法直接运行传统 Linux 版 Wine。Wine从7.0开始采用了"PE/Unix"分离的构建架构。需要从以下层面进行适配：
- **图形与窗口系统适配**：Wine 通过 `winex11.drv`、`winemac.drv`、`wineandroid.drv` 等驱动与宿主窗口系统交互。
OpenHarmony系统上需要实现类似的 `wineohos.drv` 驱动，工作内容：
* PE侧（Windows 视角）：编写wineohos.drv的Win32部分。它负责接收 Windows 应用的 CreateWindow、BitBlt 消息，然后通过 Wine的__wine_unix_call宏，跨越边界把请求吐给 Unix 侧。
* Unix侧（OpenHarmony 视角）：编写对接OpenHarmony NDK的.so代理层库。它接收到PE侧传来的请求后，调用 Rosen WM创建窗口，或者处理键鼠事件。
## 2. Wine 11 编译支持
Wine 11 版本可能需要打Musl补丁才能正常编译或者工作。这意味着：
- 需要把当前Wine对Glibc的特定接口依赖，改为Musl的接口才能正常功能。
1. 目前前我在Wine11上没有做该部分工作，MVP阶段仅做了Windows Console应用支持，如sqlite3操作数据库，运行成功。
2. adb connect ip:host不能正常，是因为在windows上adb.exe依赖wineconsole.exe创建终端窗口（从Wine日志上看到有CreateWindowEx接口调用失败输出），而我没实现窗口集成，后续验证。
- 需要分两步编译，第一步先编译Windows应用依赖的基础动态库（PE阶段），如ntdll.dll、kernel32.dll等，第二步编译宿主机依赖库（Unix 阶段），生成真正负责与OpenHarmony系统底层进行互通的桥接驱动与核心服务进程（如 wineohos.drv.so、ntdll.so）。
## 3. libfreetype 编译依赖
如果 Wine 11 需要运行 Windows GUI 应用，**必须编译并链接 libfreetype 库**，否则窗口尺寸测量会出现以下问题（我在这个问题被坑了好久😓）：
- 字体度量（metrics）获取失败，导致窗口尺寸计算错误。
- 文本渲染异常，部分控件显示空白或尺寸异常。
- 对话框布局引擎（`comctl32`、`user32`）依赖字体信息进行窗口布局。
**解决方案**：在交叉编译工具链中预先编译 `libfreetype`，并在 Wine 的 `configure` 阶段确保 `--with-freetype` 开启。
## 4. 本地窗口适配方案
### 方案一：直接调用 OHOS 窗口管理器（类似 X11/Wayland 方式）
直接调用 `OHOS::Rosen::WindowManager::Create()` 创建原生窗口，优点在于实现简单、性能开销低。但存在以下问题：
- 这部分接口属于内部接口，所以需要做一个代理层（见下面代理层部分），提供接口给wineohos.drv使用。
- **默认没有标题栏**，绘制标题栏有以下两种方式：
1. 自己实现标题栏，这样有不小额外的工作量。
2. 使用wine默认的标题栏，风格老旧。
- 窗口管理需要自行处理窗口激活、最小化、关闭等事件。
- 任务栏没有任务窗口显示，需要自己适配。
- 适用于需要深度定制的PC多窗口场景。
### 方案二：Wine Android 方式（OHOS 应用 + XComponent）
参考 `wineandroid.drv` 的适配模式：
1. 编写一个 OpenHarmony 原生应用作为宿主，内嵌 **XComponent** 用于承载 Windows 应用的图形输出。
2. XComponent 提供NativeWindow渲染接口，可以直接绑定 `wineohos.drv` 的图形缓冲区。
3. Windows 应用窗口作为子窗口嵌入到 Component中，窗口事件通过 OHOS 的输入事件通道转发。
4. 优点：可以获得完整的 OHOS 窗口生命周期管理，标题栏、导航栏、手势操作等原生支持
5. 缺点：多窗口场景下每个窗口都需要一个XComponent实例，与PC习惯不一致。
## 5. Wine 驱动层：`wineohos.drv`
在 `wine/dlls/` 目录下实现 `wineohos.drv`，作为 OpenHarmony 的 Wine 图形/窗口驱动：
```
wine/dlls/wineohos.drv/
├── ohos_window.c # 窗口创建、销毁、布局管理
├── ohos_display.c # 显示模式、屏幕信息枚举
├── ohos_keyboard.c # 键盘事件转换（OHOS KeyEvent → Win32 虚拟键码）
├── ohos_mouse.c # 鼠标事件转换
├── ohos_clipboard.c # 剪贴板桥接
├── ohos_cursor.c # 光标管理
├── ohos_gdi.c # GDI 绘图桥接
├── ohos_opengl.c # OpenGL 适配（通过 Zink 走 Vulkan）
├── ohos_vulkan.c # Vulkan 直接对接
├── ohos_icon.c # 图标管理
├── ohos_init.c # 驱动初始化与注册
├── ohos_res.c # 资源管理
└── Makefile.in # 构建配置
```
驱动内部与宿主机系统绑定，通过代理层接口调用原生OpenHarmony系统能力。
## 6. OpenHarmony 代理层
在 OpenHarmony 系统侧提供一个代理层（Native Service 或 System Ability），为 `wineohos.drv` 提供以下能力：
| 能力 | 接口 | 说明 |
|------|------|------|
| 窗口创建 | `OHOS::Rosen::WindowManager::CreateWindow()` | 创建 OHOS 原生窗口，设置窗口属性 |
| 图层拷贝 | `OHOS::Rosen::Surface::CopyLayer()` | 将 Wine 渲染的图形缓冲区拷贝到窗口图层 |
| 键鼠事件 | `OHOS::MMI::InputManager` | 监听输入事件，转发给 Wine 的输入处理 |
| 光标管理 | `OHOS::Rosen::CursorManager` | 设置/隐藏光标，更改光标样式 |
| 剪贴板 | `OHOS::MiscServices::PasteboardManager` | 同步系统剪贴板与 Windows 剪贴板 |
| 显示信息 | `OHOS::Rosen::DisplayManager` | 获取屏幕分辨率、刷新率、DPI 等信息 |
使用方式：和OpenHarmony编码一起编译出so（如libohw_proxy.z.so），导出相关的接口供`wineohos.drv`使用。
## 7. GPU 加速方案
### Vulkan 作为统一 GPU 接口
```
Windows 应用
├── Direct3D 9/10/11/12 ──→ Wine D3D 转译层 ──→ Vulkan
├── OpenGL ──→ Mesa3D Zink ──→ Vulkan
└── Vulkan ──→ 直接透传 ──→ Vulkan
│
▼
OpenHarmony Vulkan 驱动
(OHOS Vulkan ICD / Loader)
```
- **D3D → Vulkan**：Wine 内置的 `wined3d` 或 `dxvk` 项目已实现 Direct3D 到 Vulkan 的转译，性能损耗小，兼容性好。
- **OpenGL → Vulkan**：对于依赖 OpenGL 的老旧 Windows 应用，使用 **Mesa3D 的 Zink** 驱动，将 OpenGL API 调用转译为 Vulkan，无需 GL 原生驱动。
- **Vulkan 适配 OHOS**：只需在 OHOS 上实现 Vulkan 的 ICD（Installable Client Driver）和 Loader，即可运行上述所有图形栈。OpenHarmony 的 GPU 厂商（如 Mali、Adreno 等）通常已提供 Vulkan 支持。如果要自己基于Mesa3d实现Vulkan支持OHOS，可以参照其他文章。
### 优势
- 统一底层 GPU 接口，无需为 D3D 和 OpenGL 分别适配。
- Vulkan 的显存管理、管线状态、命令缓冲等机制与 Wine 的 D3D 转译层高度匹配。
- 可以利用 Vulkan 的跨平台特性，快速适配不同 GPU 硬件。
## 8. 音视频编解码
音视频编解码通过 **OHOS NDK** 提供的接口进行对接：
| 功能 | OHOS NDK 接口 | 说明 |
|------|---------------|------|
| 音频输出 | `OH_AudioRenderer` | 播放 Windows 应用的音频输出 |
| 音频输入 | `OH_AudioCapturer` | 采集麦克风输入，提供给 Windows 应用 |
| 视频解码 | `OH_AVCodec` | 硬件加速解码（H.264/H.265/MPEG4 等） |
| 视频编码 | `OH_AVCodec` | 硬件加速编码 |
| 媒体容器 | `OH_AVDemuxer` / `OH_AVMuxer` | 音视频封装/解封装 |
**适配方式**：
- 在 `wineohos.drv` 或独立的 `wineohos.media` 模块中，封装 OHOS NDK 的媒体接口。
- 通过 Wine 的 `winmm.dll`、`quartz.dll` 或 `mf.dll` 的 Hook 机制，将 Windows 多媒体 API 调用桥接到 OHOS 媒体栈。
- 利用 OHOS 的硬件编解码能力，确保音视频播放性能接近原生。
