需要增加UD中放置单个大小4G以上的文件的支持吗
在时空论坛里：http://bbs.znpc.net/forum.php?mod=viewthread&tid=6733&page=1看到这个帖子后
上面写个发起调查
我就先在这里发吧
这里人气旺
这是不点原话：
请看 asm.S 中如下变量的定义，红色标明的几个变量，采用了两个 long 整数的宽度，已经是 64 位的量了。
. = EXT_C(main) + 0x90
VARIABLE(filesize)
.long 0, 0
VARIABLE(saved_mem_upper) /* maximum contiguous memory in KB starting at 1M and below 4G */
.long 0
VARIABLE(saved_partition)
.long 0
. = EXT_C(main) + 0xA0
VARIABLE(saved_drive)
.long 0
VARIABLE(no_decompression)
.long 0
VARIABLE(part_start)
.long 0, 0
. = EXT_C(main) + 0xB0
VARIABLE(part_length)
.long 0, 0
. = EXT_C(main) + 0x120
VARIABLE(filemax)
.long 0, 0
VARIABLE(filepos)
.long 0, 0
你所说的限制，应该是 ud 文件系统的设计，不支持超过 4G 的文件。这与 FAT 文件系统不支持超过 4G 大小的文件是一样的。
使用任何软件，都有前提条件的，它都有限制的。不要超越它的限制而去使用它。
试想：你能让 FAT32 支持 4G 以上的文件长度吗？肯定不能，因为一旦 FAT32 被改造、增强为支持超过 4G 文件长度以后，它就不再叫做 FAT32 了，而成为一个全新的文件系统了。
这是它的结构定义。当初没有保留修改的余地。这是放在磁盘上的数据的结构，不是随便想改就能改的。修改了就等于制造了一个新的文件系统，不再是 UD 了，或者可以叫做 UD64。
如果改成 64 位的，会造成不兼容，与以前的各种工具都不兼容。
当然，也可以舍弃兼容性而强行修改。但这里就有一个代价问题：值不值得？这是焦点。
在 UD 区究竟有多大的必要去放置一个很大的映像文件？放在别的一个 NTFS 分区可否成为一个替代方案？
有多少人需要在 ud 区存放超过 4G 的大文件？人数少 = 意义不大。
没有不可能的事情，只有权衡。
bean 当初设计它，也就没打算支持超过 4G 的文件。
UD 的目的主要是启动，不是为了存放大文件。bean 的设计是正确的。
少数人需要存放大文件的，也一定可以用别的方法变通实现，而不一定真的需要放在 ud 区中。
如果有必要，将来可以发起一个投票，看看有多少人要求 ud 一定要支持超过 4G 的文件。
根据投票的结果，再来决定是否创造新的 UD64 格式。
就先顺着这个意思发起吧
[ 本帖最后由 2011czmxbb52 于 2012-10-8 20:20 编辑 ] 标题没讲清楚，容易让人误解。
有可能误解为放置的所有文件的总容量超过 4G。这是错误的。应该是单个文件的长度超过 4G。 UD區也不能比4GB大，data_start是uint32 U盘才4Gb的路过…… 原帖由 不点 于 2012-10-8 17:06 发表 http://bbs.wuyou.net/images/common/back.gif
标题没讲清楚，容易让人误解。
有可能误解为放置的所有文件的总容量超过 4G。这是错误的。应该是单个文件的长度超过 4G。
谢谢指点
已经修改 个人感觉没有必要。。。 UD區也不能比4GB大，data_start是uint32 目前ud可以大于4G，最大为2T
[ 本帖最后由 jianliulin 于 2012-10-9 10:03 编辑 ] 这个问题我个人可能腾不出时间来编写代码。但我可以帮助 chenall、Roy、Bean 以及其他可能的开发者们进行前期的分析准备。
目前我有两点认识：
1、这个问题根本上是修改 fbinst 格式化工具，让它产生新一代的 ud 分区（姑且称为 UD64）。从根本而言，这不是 grub4dos 的事，而是 fbinst 的事。当 UD64 诞生以后，grub4dos 需要修改代码来适应这个新的文件系统。新的文件系统有可能在一个时期内带来大量的不兼容，不兼容于以前用来操作 ud 的工具软件，包括某些 PE 中的 32 位保护模式下的 UD 工具，可能都得修改，否则可能无法支持新的文件系统。就是说，UD64 会带来不兼容。
因此，在没有足够理由的情况下，在 “ 出力不讨好 ” 的情况下，尽量应该避免去做这个工作。这是我的第一层意见。
2、技术上增强 UD 让它支持超过 4G 的大文件是可以实现的，除了前面提到的“ 肯定要产生不兼容性 ” 问题以外。
就是说，技术上不存在困难（除了 “ 肯定会带来不兼容性 ” 以外）。这是我的第二层意见。 除非特别必要，还是暂时不加的好。毕竟现在真正有这个需求的人不多。大大们有这个时间可以做些更值得做的事情。 没有必要…………………… 大于4G的文件就应该放到NTFS,exFAT可见区里面去，UD64这个文件系统很没有必要的。 我都可以，反正大大们出哪个版本我就用哪个版本。 倘若G4D能将UD MAP成一个硬盘分区出来那这个4G支持是很有必要的
应用举例在硬盘上划分UD空间 启动时G4D来引导系统，需要时，G4D能将UD空间MAP为一个硬盘分区，来做一键还原非常理想 还可以在里面让一些单文件系统 如VHDWIM等。非常安全有点HPA的感觉了。
试了一下map (ud)+1 (hd) 不成功
map (ud) (hd)是把U盘可见分区MAP成了另一个硬盘 pecmd已经可以直接把ud中的一个文件map成一个分区，很有必要支持大于4g的文件 我觉得应该向前看，如果造成不兼容，那么能用老的UD系统解决问题，不升级好了。新的文件系统主要适应新的功能。至于用哪一个版本，这是应用者自己选择的事情。 有干劲就干！ xiaoy 发表于 2012-11-3 08:41
倘若G4D能将UD MAP成一个硬盘分区出来那这个4G支持是很有必要的
应用举例在硬盘上划分UD空间 启 ...
MBROSTOOL
已经实现了UD扩展区MAP成一个硬盘分区出来。
PECMD也实现了。
grldr也实现了。(包内有)， 如果用默认的 grldr, 需要调用包内的 ldudpe来map UD。
还可以锁住UD区，防止fbtfbi等破坏。
现在 可以直接启动PE， 并在PE中加载 UD到盘符(Z:)，访问外置。
效果：
6269#
PECMD.EXE （88.05.52）UDM+FIXDRV.WCS 也支持 UDEXt
PE启动时， 自动加载UDEXt效果图：
http://bbs.wuyou.net/forum.php?mod=attachment&aid=MjA5OTQ5fDhlYWU3MTYwfDE0MjQ1MTM0OTl8NDM2MjA0fDMzMDQ5Mw%3D%3D&noupdate=yes
mdyblog 发表于 2015-2-21 18:13
MBROSTOOL
已经实现了UD扩展区MAP成一个硬盘分区出来。
PECMD也实现了。
是正常bean老大写的那个ud吧 不需要，不需要！！！！！ sunsea 发表于 2015-2-22 10:31
是正常bean老大写的那个ud吧
是滴。 本帖最后由 yjd 于 2015-2-27 12:07 编辑
mdyblog 发表于 2015-2-21 18:13
MBROSTOOL
已经实现了UD扩展区MAP成一个硬盘分区出来。
PECMD也实现了。
是个好消息。
这几天在考虑弄隐藏。。之前一直是ud和一个可见区fat32+畸形目录，中毒到不会。
ud主分区放grub4dos。可见区一堆启动文件，pe，和efi。上次文件分配表出错损坏了好多文件，修补半天-_-!!，09年到现在出现过2次。就是有时候在别人电脑有可能导致这样。
好多隐藏方案如u+啥的，都比较不适合我的文件，我是h3的pe，大多数是文件解开方案。还有efi，bootmgr启动。一丢隐藏区启动就麻烦了。。
看你介绍看来可以把这些东西丢ud的扩展区里，有空详细看看您的文章。 要是能突破单文件4g,我个人是支持的，虽然现在用vhd系统，不过对个别机还是很需要,最大好处就觉能放gho文件进ud中，比隐藏安全很多，也不会误删等多种好处 要是能突破单文件4g,我个人是支持的，虽然现在用vhd系统，不过对个别机还是很需要,最大好处就觉能放gho文件进ud中，比隐藏安全很多，也不会误删等多种好处 fbinst产生的初衷有：
1.解决不现BIOS下U盘第一扇区位置不同的问题！
2.更好的载入grldr！
而主数据区和扩展数据区是在后来加入的“附加功能”！所以，从fbinst产生的初衷来看，增加单文件4GB的支持没多价值！存GHO文件？！ 不需要
页:
[1]