2023-01-31 08:13
虽然不懂,但是觉得很牛!!!
2023-01-30 16:04
厉害了。现在国产ARM计算机风头正劲,这个可以把一些没有做移植的软件跑起来,能解决不少问题👍
2023-01-30 15:57
膜拜
2023-01-29 18:44
Wine装的软件全是各种随机莫名其妙异常,尝试过几次,体验太差了,有还不如没有
2024-01-06 11:01
wine能够运行,就已经够逆天的了,linux上面跑windows程序,这是个了不起的项目。有bug正常,但是我们要支持wine,总有一天wine能够比较完美的运行windows程序
2023-01-29 15:21
又是个CE版,后边在出个EE版。系统性污染!!!
2023-01-28 19:43
2023-01-28 13:52
Wine-CE 和 wine 是啥关系?
2023-01-28 14:02
Wine-CE是Wine的修改衍生版,另外引入了QEMU的代码,使之可以在不同指令架构上运行Win32应用。
2023-01-28 10:27
有两年没搞wine了,我重新看了一下代码,比如在ARM上,ntdll走的是signal_arm.c, 那么你处理的qemu实际上代码在signal_i386里面有,你只需要把相关代码:call_init_thunk的代码实现一下或者拷贝出来在i386代码里面跑一遍就可以了。
2023-01-27 18:59
在讨论ARM linux上模拟X86 Win32应用的模拟器的实现方案。
2023-01-27 16:52
我说的是wine有实现,你只需要把代码拷贝到ntdll pe里面,而不是在ntdll unix里面,你的ntdll pe环境就是x86,完全可以调用实现,这也是wine的实现方法,ntdll unix里面会根据arm编译去掉相关实现。
2023-01-27 12:25
啥?啥?啥?这说的都是啥?😂
2023-01-27 08:35
hangover是模拟加载的pe,你这个是模拟所有pe,和box86一样,只需要关注后端实现就可以了。l
2023-01-27 09:13
ARM根本没有fs寄存器,怎么处理。芯片指令集不同,处理器也不同,FS GS SS CS是4个段寄存器,是x86特有的。因为x86特有段间接寻址。ARM是risc,指令长度固定,不需要段寄存器。hangover失败之处就在于想用原生pe和模拟pe混合,我可以证明这是行不通的。如果客架构的某个程序需要读取该架构特有寄存器,而该寄存器的写入由其它内置dll完成,那么怎么办?模拟部分和原生部分交互的前提是两部分有且只有通过函数交互。但凡某两部分通过寄存器交互,就必须在同一态运行。你看一下芯片设计文档,寄存器与芯片设计有关,不同架构寄存器和用途都不一致。wine直到7.23,才将UNIX部分和PE部分解耦成函数调用。而PE之间存在寄存器交互现象,因此所有PE文件要在同一态下运行。
2023-01-27 11:37
这个问题是wine的问题和qemu无关,实际上你只需要在ntdll里mmap对应地址就可以了,wine的处理在ntdll unix里面,所以编译的时候去掉了相关处理,这个还涉及了teb,异常等处理,按照你的实现可以把相关代码挪到ntdll里面,这样就可以解决这个问题。
2023-01-27 13:36
如果只是teb,那么确实可以mmap解决。但是如果有个x86 app读取gs寄存器的值,而wine builtin dll需要写入这个值并传给app使用,这时用ARM的dll怎么和x86 app交互怎么办?不同体系架构间的寄存器根本无法映射对应。更何况有些寄存器的值根本不是全局的。你知道x86段寄存器内存的是什么值吗?不是地址,而是0,1,2,3等之类的索引号。需要根据索引表索引,而且索引表还是线程局部变量。这在ARM下面怎么mmap
2023-01-26 21:38
呃。。。突然想到,是不是 鸿蒙 可以跟进下?
2023-01-26 21:55
鸿蒙桌面端设备确实可以这么做。不过我这个是基于linux的,直接在鸿蒙上运行应该也可以。
2023-01-26 21:37
牛逼啊!
2023-01-26 20:16
看了一下项目才起步,你这个对于qemu用户模式启动wine区别不大,还不如隔壁家box86。wine本身实现了gdtr
2023-01-26 21:08
这个gdtr指ARM上模拟x86的GDTR,而非直接运行。我这个并非QEMU启动WINE,而是QEMU作为指令翻译层翻译Wine的EXE和DLL,另外wine的底层库仍然使用本机代码,主要好处是无需将驱动等库打包,性能上要好一些
2023-01-26 21:11
项目完成度很高了,基本上wine能运行的,我这边都能跨指令运行
2023-01-26 23:28
又仔细的看了一下,你这个跨指令切换,guest切过来的时候只支持线程启动的时候,不知道你有没有处理直接调用的情况,比如把一个指针转化为函数指针直接调用,比如msvcrt库的at函数,或者是排序函数。host调度还没有看,可以交流一下,我之前实现的思路如下:
2023-01-26 23:54
guest和host是通过协程的方式,随时可以调用。举个例子,guest把调用的host函数和参数打包成结构体,并把该结构体指针写入一个特定区域(指针大小),再把该区域指针发给host,然后切换到host协程。host二次间接寻址拿到结构体后,根据函数和参数执行,如果在执行过程中需要回调guest函数,按照相同方法定义一个结构体,把该结构体指针写入guest传入的指针对应特定区域内。然后切换到guest执行。如果任意一方没回调执行完毕,则把先前由另一方传入的结构体的函数字段置为NULL,并切换回去。如果一方发现拿到的结构体函数字段为NULL,则表示此次交互完成。
2023-01-27 00:03
你这个类似hangover,只是转发到了线程创建的地方
2023-01-26 23:32
我又仔细的看了一下,guest切换在线程创建处,host切换暂时没看,如果是函数指针直接为callback的不知道你处理了没有,比如msvcrt的一些排序回调,我之前也实现了一个类似的功能,可以交流一下
2023-01-26 23:49
看了你的atexit没有处理,这确定不会崩溃么?更不论一些apc的插入执行和线程切换了,根本不经过线程创建。你有没有测试一下wine自己纯pe的测试集。我之前的实现大概是99%支持,除了那种直接写内存拷贝汇编代码然后直接执行通过不了,其他都通过了
2023-01-26 23:56
atexit交由guest端回调处理,另外host端是可控的,没有atexit
2023-01-26 23:57
你说的是自修改代码,这个QEMU是可以检测到的,可以通过
2023-01-27 00:05
APC处理了,APC创建的线程看create_guest_thread函数,这是一个host回调guest的函数。
2023-01-27 00:17
确实,但是你都是手动加了,和hangover比不知道优势在哪里?而且有些函数指针传来传去的你都没有办法判断是host的还是guest的,你要继续优化基本很困难,特别是不好调试找出问题
2023-01-27 01:45
hangover完成度太低,很多软件都没支持,QEMU存在x86全局描述表bug,此bug会导致模拟wine时随机向fs寄存器写入脏数据从而崩溃。具体可见我的qemu的7.2.0后首个commit,里面有描述链接。但是因为找不到对此了解的同行评审人员一直没合入。
2023-01-27 08:22
回复 @范文捷 : 我觉得可能是wine的arm版本没有处理fs寄存器导致的,只有i386才用到fs寄存器。如果你用qemu完整模拟wine也有问题然后你修复了那肯定会合入。可以写个测试模拟一下环境,比如linux的i386程序操作fs寄存器
2023-01-27 08:33
回复 @范文捷 : 你这个和hangover的实现一样,但是原理有很大区别,hangover是仅模拟加载的pe文件,你这个是模拟全部pe,和box86原理一样,问题少很多,只需要关注一些后端实现就可以了,我j e
2023-01-26 18:43
“直接食用宿主的文件系统”
2023-01-27 19:01
多谢提醒,已经修改了
回复 @
{{emojiItem.symbol}}
返回顶部
顶部