（其实我没看懂你这个问题……
你已经说明白了，两种情况都可以挂载。不过第二种情况比较复杂，不像BIOS环境0x80就是第一块硬盘，在UEFI环境其实没有0x80的概念，它能不能分析，分析对不对是未知数，恐怕修改代码。没有测试，只是瞎猜想，第一种情况相对简单。
我原来是想，如果不能挂载第二种情况，我复制插槽时，就把它滤除了。
本帖最后由 slore 于 2020-11-7 11:19 编辑
2011yaya2007777 发表于 2020-11-7 11:05
之所以没有尽快上传代码，一是还有些已知遗留问题需要处理，还要清除众多的内部调试代码。二是不知道怎么 ...
GRUB4DOS的BIOS分支、UEFI分支在一起，即有继承性，又方便浏览下载。
克隆生成一个新仓库，再新开分支提交就行了。同源，代码很容易在多仓库间合并。开发履历会保留了。
代码也都在一起，也会连接到原仓库。
本帖最后由 wintoflash 于 2020-11-7 11:54 编辑
2011yaya2007777 发表于 2020-11-7 10:41
终于搞明白了，是启动 Windows 时只认第一光驱！我的电脑内存小，平时只是测试个小空壳iso，所以老是不能重 ...
我知道uefi有引导服务和运行服务性质的代码、数据。那什么时候引导服务数据被清除？是执行了启动镜像（b->start_imag）服务后，由uefi清除的吗？
boot services 里面有个 ExitBootServices。bootloader或者os kernel调用了这个之后，uefi就释放所有的boot services数据。
这个是在转圈之后调用的，应该在winload.efi里面。
我看grub2好像在引导镜像前释放了自己的内存。W大好像没有什么动作。
没有吧。uefi下grub2都是要通过boot services申请内存的，反正到系统启动的时候uefi就会自己放掉。
sunsea 发表于 2020-11-7 10:45
第一个问题盲猜是UEFI只告诉Windows这块内存没人用了，然后Windows把它加入可用内存列表分配使用，仅此而 ...
我觉得yaya想弄清楚的是，如果不加--mem，
根据slot找到【镜像所在的】【磁盘位置】，然后直接【读写磁盘】
svbus是怎么把bios下的磁盘和windows下的磁盘对上号的？
比如 (hd0,1)/xxx.vhd，是怎么对应到 E:\xxx.vhd 的。
2011yaya2007777 发表于 2020-11-7 11:14
你已经说明白了，两种情况都可以挂载。不过第二种情况比较复杂，不像BIOS环境0x80就是第一块硬盘，在UEFI ...
先复制吧，我过会回宿舍再阅读一下代码看看具体它怎么找硬盘的。
wintoflash 发表于 2020-11-7 11:59
我觉得yaya想弄清楚的是，如果不加--mem，
svbus是怎么把bios下的磁盘和windows下的磁盘对上号的？
好的，我下午晚上再看看，争取写个分析帖子出来。
将原版win10pe iso解压到FAT32分区的优盘，可以启动
然后将/EFI/Boot/bootx64.efi改名为/EFI/Boot/winpe.efi使用GRUB4DOS for UEFI无法引导
菜单：
title winpe
chainloader /EFI/Boot/winpe.efi
提示Press any key to continue...
求教怎么回事？
恭喜，终于支持EFI启动了，开始搞起来
2011yaya2007777 发表于 2020-11-7 11:05
之所以没有尽快上传代码，一是还有些已知遗留问题需要处理，还要清除众多的内部调试代码。二是不知道怎么 ...
你要是不会操作，要不先把代码传给我，我研究一下。
本帖最后由 sunsea 于 2020-11-7 17:13 编辑
// get list of disk class devices
Status = IoGetDeviceInterfaces(&GUID_DEVINTERFACE_DISK,NULL,0,&SymbolicLinkList);
if(!NT_SUCCESS(Status))
{
return Status;
}
// allocate memory for read buffer
// the minimum buffer size should be 2048 bytes for one CD/DVD-ROM sector
size = 0x800;
buf = (PUCHAR)ExAllocatePoolWithTag(PagedPool,size,SVBUS_POOL_TAG);
if(buf == NULL)
{
return STATUS_INSUFFICIENT_RESOURCES;
}
// do this for every disk in the Unicode string list
for(p = SymbolicLinkList; *p != UNICODE_NULL; p += len)
{
// do not check our own SVBus, this can BSOD with the error "System Thread Exception not handled" if we send IRP_MJ_READ in IoCallDriver of ReadWritePhysicalDisk
/*lint -save -e585 Warning 585: The sequence (??\) is not a valid Trigraph sequence */
if(RtlCompareMemory(p,L"\\??\\SVBus",(SIZE_T)0x12) != 0x12)
/*lint -restore */
{
// initialize device name unicode string
RtlInitUnicodeString(&deviceNameUnicodeString,p);
// get a pointer to the top object in the named device object's stack and a pointer to the corresponding file object
Status = IoGetDeviceObjectPointer(&deviceNameUnicodeString,FILE_ALL_ACCESS,&FileObject,&FileDeviceObject);
if(NT_SUCCESS(Status))
{
// CDROM
if(DeviceExtension->Disk.VirtualDeviceType == CDROM)
{
// read possible CD001 location of virtual ISO file on physical disk
ByteOffset.QuadPart = (LONGLONG)DeviceExtension->Disk.ImageStartOffsetInBytes + 0x8000; //算出镜像文件首地址，然后求出特征标记所在地址
}
// HDD and FLOPPY
else
{
// read possible MBR location of virtual hard disk file on physical disk
ByteOffset.QuadPart = (LONGLONG)DeviceExtension->Disk.ImageStartOffsetInBytes;//算出镜像文件首地址，然后求出特征标记所在地址
}
// zero read buffer memory
RtlZeroMemory(buf,size);
// read / write physical disk
Status = ReadWritePhysicalDisk(FileDeviceObject,FileObject,IRP_MJ_READ,buf,(ULONG)size,&ByteOffset);
if(NT_SUCCESS(Status))
{
// CDROM
if(DeviceExtension->Disk.VirtualDeviceType == CDROM)
{
// check for string "CD001"
if(buf == 'C' && buf == 'D' && buf == '0' && buf == '0' && buf == '1') //读写，检查标记，对就给过
{
// we have found a valid CDROM ISO, save file object and file device object
DeviceExtension->Disk.FileObject = FileObject;
DeviceExtension->Disk.FileDeviceObject = FileDeviceObject;
// free read buffer memory
ExFreePoolWithTag(buf,SVBUS_POOL_TAG);
// free list of disks
ExFreePool(SymbolicLinkList);
return STATUS_SUCCESS;
}
}
// HDD and FLOPPY
else if(DeviceExtension->Disk.VirtualDeviceType == HDD || DeviceExtension->Disk.VirtualDeviceType == FLOPPY)
{
// check for last 2 bytes of a valid MBR
if(buf == 0x55 && buf == 0xAA) //读写，检查标记，对就给过
{
// we have found a valid MBR, save file object and file device object
DeviceExtension->Disk.FileObject = FileObject;
DeviceExtension->Disk.FileDeviceObject = FileDeviceObject;
// free read buffer memory
ExFreePoolWithTag(buf,SVBUS_POOL_TAG);
// free list of disks
ExFreePool(SymbolicLinkList);
return STATUS_SUCCESS;
}
}
}
// we have not found a CDROM ISO or an MBR
// dereference the file object, this will also indirectly dereference the device object
ObDereferenceObject(FileObject);
}
}
// get Unicode string length of physical disk
// add 2 bytes for Unicode terminating null and continue with the next physical disk in the list
len = wcslen(p) + 1;
}
SVBus作者思路就两部：
1，算出镜像文件应该所在物理磁盘上的位置
2，根据位置，逐个检查物理磁盘，读指定位置，看有没有特征标记，有就给过，不再检查
跟那些0x80 0x81没有任何关系……这个思路我只能说牛逼，用最小的代码量覆盖了99%的情况……毕竟两个磁盘上同一位置都有有效标记很罕见……也意味着这个方案应该是可以移植到UEFI下的……
sunsea 发表于 2020-11-7 17:09
SVBus作者思路就两部：
1，算出镜像文件应该所在物理磁盘上的位置
2，根据位置，逐个检查物理磁盘，读 ...
这还真是简单粗暴。
那map信息里面的CHS什么的也用不到吧，只要文件在磁盘上的扇区号或者内存地址信息就行了。
wintoflash 发表于 2020-11-7 19:37
这还真是简单粗暴。
那map信息里面的CHS什么的也用不到吧，只要文件在磁盘上的扇区号或者内存地址信息就 ...
似乎还是用了，因为Windows会询问这些磁盘参数，所以Slots里是啥SVBus就填的啥。
liuzhaoyzz 发表于 2020-11-6 13:29
title /EFI/Microsoft/Boot/bootmgfw.efi
find --set-root /EFI/Microsoft/Boot/bootmgfw.efi
chainloa ...
感谢指导，现在提示：
（hd0,0）
Press any key to continue...
menu.lst写的是：
timeout 55
default 0
font /GRUB/unifont.hex.gz
title /EFI/Microsoft/Boot/bootmgfw1.efi
find --set-root /EFI/Microsoft/Boot/bootmgfw1.efi
chainloader /EFI/Microsoft/Boot/bootmgfw1.efi
hyde777 发表于 2020-11-7 12:18
将原版win10pe iso解压到 FAT32分区的优盘，可以启动
然后将/EFI/Boot/bootx64.efi改名为/EFI/Boot/winp ...
同问Press any key to continue...
我启动bootmfw也是这样
本帖最后由 2011whp 于 2020-11-8 11:31 编辑
sunsea的系统虚拟总线驱动（svbus)搞的怎么样了，期待中
好像 直接找文件，
希望g4e，在这里留下的标准的 标识变量，并公布出来，最好不是一个ISO，而是总线集合变量
让其它引导也 照样做，形成标准，有利于RAMOS，同时也有利于周边开发
GUID 就用 sunsea建议的 {621F0DF7-B6BB-4334-B16B-3C8AFC883B3A}
似乎还是用了，因为Windows会询问这些磁盘参数，所以Slots里是啥SVBus就填的啥
我想了解SVBus使用插槽的情况，可否上传源代码？
本帖最后由 sunsea 于 2020-11-8 12:43 编辑
2011yaya2007777 发表于 2020-11-8 11:48
我想了解SVBus使用插槽的情况，可否上传源代码？
https://sourceforge.net/projects/svbus/
在这里直接下载，程序包里就有源代码。
搜索关键词是slots。有什么内核相关的函数看不懂可以问我。
摘录一些：
DeviceExtension->Disk.DiskGeometry.TracksPerCylinder = DriverExtension->slot.max_head + 1;
DeviceExtension->Disk.DiskGeometry.SectorsPerTrack = DriverExtension->slot.to_sector;
DeviceExtension->Disk.DiskGeometry.BytesPerSector = DeviceExtension->Disk.SectorSize;
DeviceExtension->Disk.DiskGeometry.Cylinders.QuadPart = (LONGLONG)((DeviceExtension->Disk.ImageSizeInLBAs / DeviceExtension->Disk.DiskGeometry.TracksPerCylinder) / DeviceExtension->Disk.DiskGeometry.SectorsPerTrack);↑CHS直接引用slot
if(DriverExtension->slot.from_cdrom == 1)
{
// set device type and characteristics to CDROM
DeviceType = FILE_DEVICE_CD_ROM;
DeviceCharacteristics = FILE_REMOVABLE_MEDIA | FILE_READ_ONLY_DEVICE | FILE_AUTOGENERATED_DEVICE_NAME | FILE_DEVICE_SECURE_OPEN;
}
// HDD and FLOPPY
// from_cdrom == 0
else
{
// FLOPPY
if(DriverExtension->slot.from_drive < 0x80)
{
// set device type and characteristics to FLOPPY
DeviceType = FILE_DEVICE_DISK;
DeviceCharacteristics = FILE_REMOVABLE_MEDIA | FILE_FLOPPY_DISKETTE | FILE_AUTOGENERATED_DEVICE_NAME | FILE_DEVICE_SECURE_OPEN;
}
// HDD
else
{
// set device type and characteristics to HDD
DeviceType = FILE_DEVICE_DISK;
DeviceCharacteristics = FILE_AUTOGENERATED_DEVICE_NAME | FILE_DEVICE_SECURE_OPEN;
}
}
↑根据from_drive判断类型。
// RAM image
if(DriverExtension->slot.to_drive == 0xFF)
{
// set image type to RAM and copy image type string
DeviceExtension->Disk.ImageType = RAM;
swprintf(DeviceExtension->Disk.wszImageType,L"RAM");
}
// DISK image
else
{
// set image type to DISK and copy image type string
DeviceExtension->Disk.ImageType = DISK;
swprintf(DeviceExtension->Disk.wszImageType,L"Disk");
}
↑根据to_drive判断镜像所在位置。
// do not subtract one sector for the VHD image footer, because we have a floppy image
DeviceExtension->Disk.ImageSizeInLBAs = DriverExtension->slot.sector_count;
↑计算磁盘长度。
// calculate image start offset in bytes
// start sector is always based on 512 byte sectors of the HDD
DeviceExtension->Disk.ImageStartOffsetInBytes = DriverExtension->slot.start_sector * 512;↑计算在磁盘上的起始地址。
其他参数好像没用，不过为了保持结构一致和地址不变的话还是保留吧？反正也不占多少空间。
本帖最后由 2011yaya2007777 于 2020-11-8 13:04 编辑
在这里直接下载，程序包里就有源代码
谢谢了。主要是我认为在 UEFI 环境下，chs 参数无用，插槽的 chs 位置被其他参数占用。看来换得做些调整。
那个网站打不开！
2011yaya2007777 发表于 2020-11-8 13:03
谢谢了。主要是我认为在 UEFI 环境下，chs 参数无用，插槽的 chs 位置被其他参数占用。看来换得做些调整 ...
Here。里面的SVBus/src文件夹。
我也是很好奇，都0202年了，为什么Windows还要询问磁盘的CHS……M$真的不知道几乎所有磁盘都是线性寻址了吗……0202年了不是1999年啊……
终于支持 UEFI 了，太好了！
liuzhaoyzz 发表于 2020-10-30 16:07
其实我一直在想能否和BIOS下的grub4dos共用一套菜单，比如MBR磁盘，根目录下有一个menu.lst，BIOS ...
我也想共用一套菜单，建议还是尽量兼容原有的版本命令。
另外，这个版本，搜索菜单并不是默认从根目录开始的：我的机上，EFI分区里有GRUB目录的MENU.LST文件，根目录下也有，结果启动后使用的是GRUB目录下的，而非根目录下的。
有阴也有阳 发表于 2020-11-1 00:15
提一个建议，能否把支持UEFI启动的menu.lst菜单的位置设置成EFI/grub/menu.lst，
而原来只支持B ...
附议！这样即使不能同一套菜单，也不至于混乱了。
下载了一楼的20201029版本试了下，发现不支持 LZMA 压缩格式、map --mem 不支持 --top 参数。还有，使用 chainloader /bootmgr 提示“cannot load image”，出错信息是“Invalid or unsupported executable format”。使用 chainloader /efi/microsoft/boot/bootmgfw.efi 命令，在输入 boot 后会返回到 grub> 命令行格式。手中有支持传统或/和 EFI 启动的 PE 镜像，没有一个能够启动的。
我是在真机上试的，G5400 CPU + H110主板，BIOS 设置可以双启动，平时默认传统方式启动，测试 G4D 时按 F11 选择 EFI 启动。一个 MBR 格式 120GB SSD 硬盘，分为安装非EFI的WIN7系统分区和工具数据两个区，无 EFI 分区，G4D 识别为 (hd1)；另有一个 4TB 机械硬盘，分三个分区，其中第一个分区是 MSR，第二三分区是EFI启动的WIN10系统分区和数据分区，第四个分区是 EFI 分区，G4D识别为 (hd0,3)，而 G4D 文件就放在这分区中。
现在感觉连 Windows 都启动不了，一点实用性都没有啊，哪里出错了？
现在没有 --top 这个参数。
chainloader 只能加载 .efi 文件，或者光盘，硬盘。
如果你使用 bootmgfw.efi （或者名称不同，但是内容相同）启动的， 则不能再加载它。
发现不支持 LZMA 压缩格式
应当支持，但是我没有测试。
本帖最后由 2011yaya2007777 于 2020-11-9 07:59 编辑
W大，我 --mem 使用的是 GRUB_EFI_LOADER_DATA，这个不知道会不会被释放？
对于分配页，分配池，我有些疑惑，不知道他们的区别，什么时候使用哪一个?
xianglang 发表于 2020-11-8 18:17
下载了一楼的20201029版本试了下，发现不支持 LZMA 压缩格式、map --mem 不支持 --top 参数。还有，使用 ch ...
“测试 G4D 时按 F11 选择 EFI 启动”---- 问题可能就出在这里。
yaya的这个版本G4D，我测试的结果，貌似需要纯UEFI环境
(BIOS/UEFI设置里---选择UEFI OS/关闭安全启动/关闭CSM)。
按Fn键从快捷启动菜单中选UEFI是不行的，那样选择的话，
G4D会直接进入命令行状态。
本帖最后由 wuwuzz 于 2020-11-8 21:10 编辑
一个小插曲，关于CHS。
我认为，CHS不可或缺。从流出的BIOS/UEFI源代码来看：
在BIOS下
即使引导软件不用CHS，不代表BIOS不用。BIOS在U盘枚举时，(尚未进入引导阶段时)，
即开始计算U盘逻辑CHS参数(并计算完毕)，等待调用(例如等待用户调用INT 13 Fn8)。
在UEFI下，参见
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=421614
===========
关于windows，记得很久以前，MS的知识库里，谈到NT处理MBR时，有关于
CHS处理方面的内容，时间久远，记不太清了。但有一点，我记得清楚，
实在搞不定硬盘CHS的准确性时，终极办法就是以物理(固件)CHS为基准。
U盘也是同样的道理，BIOS/UEFI计算的基础，就是U盘物理(固件)CHS。
wuwuzz 发表于 2020-11-8 21:09
一个小插曲，关于CHS。
我认为，CHS不可或缺。从流出的BIOS/UEFI源代码来看：
很好奇一个问题，保留CHS除了兼容旧软件之外的意义在哪里？难道有固件或者软件到现在了线性寻址也给不出正确结果？
本帖最后由 wuwuzz 于 2020-11-9 09:26 编辑
sunsea 发表于 2020-11-9 01:14
很好奇一个问题，保留CHS除了兼容旧软件之外的意义在哪里？难道有固件或者软件到现在了线性寻址也给不出 ...
是的，兼容老标准这个原因是确定无疑的。只要INT13还在，CHS就如影相随。
从代码上看，到了UEFI，似乎也没能把CHS完全剔除掉，历史的遗产(包袱)
太多了。
wuwuzz 发表于 2020-11-9 09:23
是的，兼容老标准这个原因是确定无疑的。只要INT13还在，CHS就如影相随。
从代码上看，到了UEFI，似乎也 ...
可还行……那为什么不统一H255S63然后内部转成线性地址呢……还是有老的/不规范固件给不出正确结果还是咋滴……
 |