ARM根本没有fs寄存器,怎么处理。芯片指令集不同,处理器也不同,FS GS SS CS是4个段寄存器,是x86特有的。因为x86特有段间接寻址。ARM是risc,指令长度固定,不需要段寄存器。hangover失败之处就在于想用原生pe和模拟pe混合,我可以证明这是行不通的。如果客架构的某个程序需要读取该架构特有寄存器,而该寄存器的写入由其它内置dll完成,那么怎么办?模拟部分和原生部分交互的前提是两部分有且只有通过函数交互。但凡某两部分通过寄存器交互,就必须在同一态运行。你看一下芯片设计文档,寄存器与芯片设计有关,不同架构寄存器和用途都不一致。wine直到7.23,才将UNIX部分和PE部分解耦成函数调用。而PE之间存在寄存器交互现象,因此所有PE文件要在同一态下运行。
Wine-CE 首个正式版发布,可跨指令架构运行程序的 Wine
Wine-CE 首个正式版v8.0发布,该版本基于Wine 8.0和Qemu 7.2.0,可在ARM平台上运行x86 Win32程序。在此版本之前,已发布2个预览版。并已经在树莓派4平台上成功进行了测试。
和其它在ARM平台上运行x86应用程序的方案相比,该方案将指令翻译层,即修改过的Qemu,嫁接于Wine的Windows Dll层和Unix库层之间,从而遵循了非必要不模拟的原则,即只对x86架构的Windows Dll和所模拟的应用程序进行翻译,并且和原生的Wine共用一套Unix库。从而可以直接使用宿主架构ARM的库和驱动,避免了图形API等底层库和驱动的模拟工作。相比其它方案,该项目可直接使用宿主的文件系统,无需rootfs和chroot操作,从而无需root权限也可正常使用。
该项目基于Wine和Qemu项目的最新稳定版分支,并充分利用Wine和Qemu的最新特性。在此项目的开发过程中,修复了Qemu x86用户模式下的全局描述表(GDT)bug,该bug会导致多线程运行时所模拟的段寄存器值被意外修改。由于此bug的修复,Wine-CE可以直接将Qemu的无软页表用户模式作为指令翻译层,从而让模拟层和本基层使用共同的内存地址空间,进而保证两者间通过协程方式进行双向快速交互。
另外,此项目使用了DXVK作为Direct3D的实现。和其它项目相比,此项目将DXVK进行了修改,使之可以在树莓派上运行。因此,针对Direct3D程序的执行,会将Direct3D调用翻译为Vulkan调用,交由宿主端本机执行,从而大幅提升图形渲染性能,为3D游戏的运行打好基础。
Wine-CE项目在仓库中不但提供了完整的源码和构建过程描述,还提供了二进制包,可以快速部署到机器上进行执行。
项目地址: https://gitee.com/fanwenjie/wine-ce
测试视频如下:
测试平台:Raspberrypi 400
仙剑奇侠传 3:https://www.bilibili.com/video/BV1Kd4y157Lm
魔兽争霸 III:https://www.bilibili.com/video/BV1qK411k7mu