|
|
本帖最后由 liuzhaoyzz 于 2020-12-26 18:47 编辑
我补充和澄清一些事情。
Wintoflash大神在2019-11-5日在论坛公布了支持map的grub2_UEFI，2011yaya2007777参考了grub2 map的部分代码发起了grub4dos_UEFI项目，2020-8-27和2020-10-29在论坛发布了32位和64位的g4e，Wintoflash在2020-11-1说，reboot.pro那边的一些网友（荷兰的wimb，墨西哥的alacran等等），想启动 RAMOS 的 VHD，sunsea加入了讨论，从svbus源代码级别进行了解读支持，国外的Taviruni和alacran在2020-12-5日成功地用g4e的map --mem把vhd加载到了低位内存并启动，Wintoflash告知了这个消息，让我和sunsea尝试下，12-7日我联系了朱玛制作了签名版的svbus驱动，驱动签名完成之后，发现g4e只能把vhd加载在低位内存，yaya修改了g4e，添加了--top参数强制加载到高位内存，但启动svbus驱动的vhd还是失败，12-9日我在微软知识库里面发现如果采用EFI_RUNTIME_SERVICES_DATA类型的内存盘，启动的时候会和windows内存分配冲突，yaya把内存盘改成了EFI_RESERVED_MEMORY_TYPE的类型，我试了下，第一次成功启动了基于svbus驱动双分区vhd-UEFI-RAMOS，我写了一篇《基于svbus驱动+grub4dos或grub2制作的UEFI-WIN10RAMOS和BIOS-WIN10RAMOS教程》，后来Wintoflash大神又给g4e添加了load命令可以加载ntfs.efi驱动，g4e/grub2成功启动了基于svbus驱动单分区vhd-UEFI-RAMOS。
到了这个时候（2020-12-12日），svbus驱动基本完成了通杀WIN7 8 10的vhd-UEFI-RAMOS，svbus基本上可以告一段落了。grub2的map机制我在2019-11-9在grub2那个帖子也做过尝试，那时候g4e/grub2还没有完成和svbus驱动的对接完善。svbus这些成功的经验告诉我们，g4e/grub2的map --mem机制已经非常成熟了，我就想着用g4e/grub2的直接map模式（不带mem的）尝试下启动primo驱动的vdf镜像，这个时候感觉“万事俱备，只欠东风”了，东风就是让windows识别grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)仿真出来的虚拟磁盘，正常引导BCD，我在《基于svbus驱动+grub4dos或grub2制作的UEFI-WIN10RAMOS和BIOS-WIN10RAMOS教程》里面也说了这个事情。经过反复尝试，以及Wintoflash详细的解答支持，我在2020-12-22日成功制作了grub2启动win8.1-primo-uefi-RAMOS成功启动，开始菜单左键、右键，系统托盘区WIFI、音量全部正常，后来经过摸索g4e/grub2成功完成了通杀WIN7 8 10--primo-uefi-RAMOS，这是不依赖于微软ramdisk.sys驱动的全新Primo-UEFI-RAMOS方案，单镜像、双镜像陆续搞定，更多的compact、wimboot等方案已经在路上，一个全新的UEFI-RAMOS时代已经到来！
再看下楼主发的帖子，中心思想就是你在群里说的那两句话，“UEFI-RAMOS驱动方案来源于群里”和“svbus没什么用”。我听到这样的话感到很气愤，我很早就已经退群了（后来虎大拉我我又退了），2020-12-12日svbus搞定后，我跟虎大聊了聊，希望他能够研究下基于直接map模式（不带mem的）启动的primo驱动UEFI-RAMOS方案，虎大给我说了下你们搞的imgboot方案，这个方案是基于UEFI-SHELL下的方案，类似于g4e的map --mem启动vdf，然后通过bootmgfw.efi加载vdf镜像，这样的方式就存在单镜像vdf必须小于3.2GB的限制，而且不能跨越高低位内存，实战上来讲没有意义；双镜像的制作方案，由于dido没有公布修改MBR的imgboot版本，所以虎大也没有在论坛公布双镜像制作方案。而我一直不想跑去UEFI-SHELL下面绕弯解决问题，SHELL就好比是DOS，现在的g4e/grub2相当于windows时代，已经形成了一个OSloader的生态圈，有一套完整的引导、仿真、驱动这些，是一套完整的解决方案，这套方案已经通过svbus驱动的成功得到了证实，我感觉离Primo-UEFI-RAMOS成功只有一步之遥，只需要验证即可，RAMOS启动理论已经有了，引导器、磁盘仿真、primo驱动，什么都有了。虎大的imgboot方案我大概试了下没有成功，我对uefi-shell也没有什么兴趣，最后还是通过研究搞定了直接map vdf镜像启动primo-uefi-RAMOS，这是一套全新的primo-uefi-RAMOS方案，根本不涉及imgboot启动环节，没有imgboot方案的那些问题，单镜像体积没有3.2GB的限制，双镜像也没有什么限制。我很早就不在小群里了，Wintoflash也很早就退群了，2011yaya2007777在群里？sunsea在群里？国外的网友在群里？大家人都不在群里，你怎么敢说“UEFI-RAMOS驱动方案来源于群里”这样的话？如果说Wintoflash大神借鉴了dido的部分代码，那也仅仅是借鉴了map --mem这样子的代码，而imgboot方案类似于map --mem，我的新方案是直接map，别看差了一个字，后面的所涉及到的技术原理完全不同。你去看看g4e/grub2的那两个帖子里面，svbus测试、反馈过程中经历了怎样的挫折？我在跟踪、测试、反馈g4e/grub2的过程中，没见到你参与多少。Wintoflash和2011yaya2007777做了多少次调整和改进，就因为Wintoflash参考了下dido的代码，所以“UEFI-RAMOS驱动方案来源于群里”？dido的源代码总行数: 2355行。grub2里面c语言源代码总行数: 342703行，每行代码就算30个字，也有接近100万字代码，这是个浩大的工程，Wintoflash大神一度曾经想放弃这个项目，他在github上面有1万多个commits，两个根本不是一个数量级的。你只看到了Wintoflash大神借鉴dido关于map --mem的代码这一个很小的“点”，却忽视了后续众多用户测试、反馈，Wintoflash改进的这个“面”，眼光实在狭窄。g4e/grub2+svbus-UEFI-RAMOS方案和g4e/grub2+primo-uefi-RAMOS根本就不是来自群里。
没有svbus成功的技术和经验积累，primo驱动不会在2020-12-12～2020-12-22日短短的十天之内有突破性的进展，怎么svbus就没用了？大家研究UEFI-RAMOS技术很多年了，都是基于微软的ramdisk.sys驱动来搞，受制于3.2GB左右镜像的限制，一直没有什么突破，UEFI下svbus驱动突破了这个限制，而且svbus是开源免费的解决方案，没有软件版权的问题，是非常稳定、完整的方案，制作起来异常简单，它要比所有基于微软ramdisk驱动的方案都要好，g4e/grub2+svbus-UEFI-RAMOS方案的成功，让所有基于微软ramdisk.sys驱动的方案黯然失色。Wintoflash大神在2019-11-5日在论坛公布了支持map的grub2_UEFI，时间已经过去了一年多，可是大家一直没有基于这个map搞定UEFI-primo-RAMOS，正是因为有了svbus成功过程中的技术和经验积累，g4e/grub2+UEFI-primo-RAMOS才得以在这么短暂的时间内取得成功，对你没用的方案对别人很有用。primo驱动还有软件版权的问题。
三观不同，话不投机半句多。既然说“UEFI-RAMOS驱动方案来源于群里”，我就故意不发制作教程，我看看小群里有多少人能够制作出基于g4e/grub2启动的primo-uefi-RAMOS，事实上，只要手工制作过BIOS下面的RAMOS，对照着做，很轻松就能够成功，根本不需要教程。
|
|
IP卡
狗仔卡
发表于 2020-12-26 13:20:10
显身卡