需要增加UD中放置单个大小4G以上的文件的支持吗

sunsea

在时空论坛里：http://bbs.znpc.net/forum.php?mo ... 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 编辑 ]

sunsea

原帖由 不点 于 2012-10-8 17:06 发表
标题没讲清楚，容易让人误解。

有可能误解为放置的所有文件的总容量超过 4G。这是错误的。应该是单个文件的长度超过 4G。

谢谢指点
已经修改

sunsea

mdyblog 发表于 2015-2-21 18:13
MBROSTOOL
已经实现了  UD扩展区  MAP成一个硬盘分区出来。
PECMD也实现了。

是正常bean老大写的那个ud吧