学习了{:soso_e100:}

嗯，当初是在SYSOFT时空论坛看到chenall这个首创的。
后来我试着把东西大规模续到grldr尾部发现并不影响grldr运行，而提取尾部的东西来用也可以做到，就使用了“续尾”这个词。

回头看，grldr/grub.exe本身其实一直也是将4KB菜单续到程序末尾（构成内置菜单）的。
进一步，grldr/grub.exe程序则是g4d主体（stage2之类）尾续到头部的结果。
启动时，grldr/grub.exe头部先被加载，然后由头部代码加载执行其尾续的grldr/grub.exe主体，由主体加载执行尾续的内置菜单。

不点大人把字库压缩放在内置菜单末尾，使得中文菜单无须另外携带字库文件，也是一种“续尾”。

“续尾”（/"尾续”）基于grub4dos实现了单文件化。

pseudo 发表于 2015-1-31 15:42
只是回复20楼网友，为他需要的“样子”提供相关参考资料。
跟尾续批处理史无关，楼主勿误会。

http://chenall.net/post/grub4dos_menu/

这个应该是能找到的最早的尾续原型了

对于批处理来说如果文件比较多而且都是小文件时才需要尾续,如果文件比较大,则不建议尾续,因为这样子运行时加载的速度会比较慢(需要把整个文件读放到内存中).

但是如果文件都是批处理文件执行一定要用到的模块那还是用尾续吧,这样运行速度会比较快.

chenall 发表于 2015-1-25 08:02
另外有没有考虑支持文件夹?

一般不需要，实在需要尾续一个小的img就可以了

jianliulin 发表于 2015-1-29 12:45
不好意思！！ 我是凭记忆写的， 已修正，

只是回复20楼网友，为他需要的“样子”提供相关参考资料。
跟尾续批处理史无关，楼主勿误会。

变量出现之前，可能chenall已用过尾续技术；
usb_acc.0pe算早期尾续批处理一例，但未必是最早的。变量、批处理出现之后，我g4d用的少了。

pseudo 发表于 2015-1-29 12:24
变量、批处理出现之前，史前续尾的样子：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=154873
fb ...

不好意思！！ 我是凭记忆写的， 已修正，

变量、批处理出现之前，史前续尾的样子：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=154873
fbinstTool管理批处理之前，批处理续尾一例：
http://bbs.wuyou.net/forum.php?m ... 655&pid=2435372

chenall 发表于 2015-1-25 08:02
另外有没有考虑支持文件夹?

C大我觉得像 RUN 这类外部命令的结构，应当在帮助文档批处理尾续文件做一介绍，
   他的一代是什么样子  二代 三代是什么样子
   必竟  很多人  不知道 RUN  WEE   这些文件构造
   

jianliulin 发表于 2015-1-27 17:20
zxw ，就等你出现了，我再0pe的群里呼唤你，没收到回应，你有没有时间用新的批处理重新实现你的run，现在 ...

应你要求制作了一个新的。
[20150128]自动列表·自动菜单·数字启动
http://bbs.wuyou.net/forum.php?m ... &fromuid=286511
(出处: 无忧启动论坛)

好，改天抽空弄一下

zxw 发表于 2015-1-27 13:04
好东西，支持一个。

zxw ，就等你出现了，我再0pe的群里呼唤你，没收到回应，你有没有时间用新的批处理重新实现你的run，现在都离不开你的run了。

刚才又试了一下，连grub4dos的模块文件都可以附加到批处理，然后用insmod命令安装。

好东西，支持一个。

嗯,确实有需要文件夹的,可以自己整,也可以直接用ISO文件

chenall 发表于 2015-1-25 08:02
另外有没有考虑支持文件夹?

文件夹会把简单的问题复杂化，尾续的文件一般不会很多

{:soso_e179:}{:soso_e179:}太棒了，谢谢！！！

lzma file format

lzma 文件格式说明

1. File Format

1. +-+-+-+-+-+-+-+-+-+-+-+-+-+==================+
   
2. |         Header          |        LZMA Compressed Data   |
   
3. +-+-+-+-+-+-+-+-+-+-+-+-+-+==================+

复制代码

lzma 文件由头部和压缩了的数据构成。头部是 13 个字节。

        The .lzma format file consist of 13-byte Header followed by
        the LZMA Compressed Data.

        Unlike the .gz, .bz2, and .xz formats, it is not possible to
        concatenate multiple .lzma files as is and expect the
        decompression tool to decode the resulting file as if it were
        a single .lzma file.

        For example, the command line tools from LZMA Utils and
        LZMA SDK silently ignore all the data after the first .lzma
        stream. In contrast, the command line tool from XZ Utils
        considers the .lzma file to be corrupt if there is data after
        the first .lzma stream.


1.1. Header

1. +------------+----+----+----+----+--+--+--+--+--+--+--+--+
   
2. | Properties |  Dictionary Size  |   Uncompressed Size   |
   
3. +------------+----+----+----+----+--+--+--+--+--+--+--+--+

复制代码

头部的格式，第一字节是属性字节，它的最大值是 (4*5+4)*9+8=224=0xE0，如果超过这个值，那就不是 lzma 格式。

1.1.1. Properties

        The Properties field contains three properties. An abbreviation
        is given in parentheses, followed by the value range of the
        property. The field consists of

            1) the number of literal context bits (lc, [0, 8]);
            2) the number of literal position bits (lp, [0, 4]); and
            3) the number of position bits (pb, [0, 4]).

        The properties are encoded using the following formula:

            Properties = (pb * 5 + lp) * 9 + lc

        The following C code illustrates a straightforward way to
        decode the Properties field:

            uint8_t lc, lp, pb;
            uint8_t prop = get_lzma_properties();
            if (prop > (4 * 5 + 4) * 9 + 8)
                return LZMA_PROPERTIES_ERROR;

            pb = prop / (9 * 5);
            prop -= pb * 9 * 5;
            lp = prop / 9;
            lc = prop - lp * 9;

        XZ Utils has an additional requirement: lc + lp <= 4. Files
        which don't follow this requirement cannot be decompressed
        with XZ Utils. Usually this isn't a problem since the most
        common lc/lp/pb values are 3/0/2. It is the only lc/lp/pb
        combination that the files created by LZMA Utils can have,
        but LZMA Utils can decompress files with any lc/lp/pb.

紧接属性字节之后，是4字节的整数，表示本次压缩所采用的字典的长度。一般的 lzma 格式，其字典长度可以是任意值。但 grub4dos 不承认那些太过任意的字典长度。grub4dos 只承认字典长度为 2 的 n 次方的 lzma 头部，否则，如果不是 2 的 n 次方，那么 grub4dos 就不把它当作 lzma 格式来对待。

1.1.2. Dictionary Size

        Dictionary Size is stored as an unsigned 32-bit little endian
        integer. Any 32-bit value is possible, but for maximum
        portability, only sizes of 2^n and 2^n + 2^(n-1) should be
        used.

        LZMA Utils creates only files with dictionary size 2^n,
        16 <= n <= 25. LZMA Utils can decompress files with any
        dictionary size.

        XZ Utils creates and decompresses .lzma files only with
        dictionary sizes 2^n and 2^n + 2^(n-1). If some other
        dictionary size is specified when compressing, the value
        stored in the Dictionary Size field is a rounded up, but the
        specified value is still used in the actual compression code.

紧接着字典长度，就是文件未压缩的长度值，换句话说，就是解压后的长度值。这个长度值占用 8 字节，是 long long 类型的整数。
普通的 lzma 文件，其解压后的长度域可以是 0xFFFFFFFFFFFFFFFF （即负的 1），但 grub4dos 不承认这样的 lzma 格式。也就是说，为了让 grub4dos 承认它是 lzma 格式，其解压后的长度域不可以是负1。


1.1.3. Uncompressed Size

        Uncompressed Size is stored as unsigned 64-bit little endian
        integer. A special value of 0xFFFF_FFFF_FFFF_FFFF indicates
        that Uncompressed Size is unknown. End of Payload Marker (*)
        is used if and only if Uncompressed Size is unknown.

        XZ Utils rejects files whose Uncompressed Size field specifies
        a known size that is 256 GiB or more. This is to reject false
        positives when trying to guess if the input file is in the
        .lzma format. When Uncompressed Size is unknown, there is no
        limit for the uncompressed size of the file.

        (*) Some tools use the term End of Stream (EOS) marker
            instead of End of Payload Marker.

以上就全部解释了头部 13 个字节的意义。一个属性字节，四个字节的字典长度，八个字节的解压后长度。

接下来就是压缩数据了，没有什么可解释的。仅就判断 lzma 格式的合法性而言，grub4dos 不检查压缩数据的结构。待到真正开始读文件的时候，才去从压缩数据中抽取解压后的数据。

1.2. LZMA Compressed Data

        Detailed description of the format of this field is out of
        scope of this document.


2. References

        LZMA SDK - The original LZMA implementation
        http://7-zip.org/sdk.html

        7-Zip
        http://7-zip.org/

        LZMA Utils - LZMA adapted to POSIX-like systems
        http://tukaani.org/lzma/

        XZ Utils - The next generation of LZMA Utils
        http://tukaani.org/xz/

        The .xz file format - The successor of the .lzma format
        http://tukaani.org/xz/xz-file-format.txt

另外有没有考虑支持文件夹?

jianliulin 发表于 2015-1-24 22:03
1.左边文件名问题，在一楼有说明，取的不是导入文件的文件名，
2.是否把混合模式去掉，只保留尾续数据文件 ...

现在只使用数据模式,这样比较简单,不会混乱.

支持一个.

现在可能存在bug,过几天再发布到usb板块

发现最新版不在USB启动区发布啦{:soso_e113:}

1.左边文件名问题，在一楼有说明，取的不是导入文件的文件名，
2.是否把混合模式去掉，只保留尾续数据文件功能



为了操作简单，已经去掉尾续批处理，更新在顶楼

首先一个BUG,左边添加默认的文件名有问题.

另外为了使用方便,建议大家把批处理等所有的文件都附加为数据文件,这样很容易访问(就是把批处理也作为数据文件)

这样访问很方便例子(只附加数据文件)

!BAT
:: 列出附加的数据文件列表
ls %~m0/
::显示数据文件里面test.bat的内容
cat %~m0/test.bat
::直接执行
%~m0/test.bat

如果是混合模式(批处理区和数据区都有的话)要访问数据区会麻烦一些...我们目前只能使用%~m0来访问尾续文件

好新鲜                                       .

cpio中有保存文件名，但左边的批处理不在cpio中，右边的才在，忘记上传新的fbt了，已补上，在顶楼

6.由于批处理在尾续后是不保存文件名，访问也是基于在尾续中的顺序，所以fbinsttool对尾续的批处理做了一下约定

用CPIO有保存文件名的吧,
有文件名,可以在批处理中用文件名来调用的(如果有目录的话也是可以的)