无忧启动论坛

标题: grub4dos尾续批处理史记 [打印本页]

作者: jianliulin 时间: 2015-1-24 20:42
标题: grub4dos尾续批处理史记
本帖最后由 jianliulin 于 2015-2-3 08:30 编辑

什么是grub4dos的尾续批处理？

以!BAT 开头的文本文件在grub4dos里面就会被认为是可以执行的批处理，和windows下*.bat差不多，而尾续批处理就是在批处理后面附加一些额外的数据，在执行
批处理的时候默认会被忽略，但用户可以在批处理里面用命令取出此部分数据来使用，附加了这样额外数据的批处理我们习惯称作尾续批处理。

grub4dos发展到现在这个样子不一天两天造就的，其中尾续批处理到目前就升级了三代，以run为尾续批处理的代表作。

第一代
批处理功能刚出来的时候觉得很方便，再后来发现要调用一些外部数据，比如字体、FIRADISK驱动等等，发布自己的批处理时候还必须附带这样那样的文件，
最不方便的还是有些用户不会用或者用错，后来使用了一个办法，将需要的这种外部文件打包成一个img然后附加到批处理后面，并且记录img
相对批处理的偏移量和大小，在批处理中把img map成一个内存盘，然后使用。因为如果批处理变大或者变小都必须重新修正img的偏移量，所以很麻烦，但却是解决了只要发
布一个批处理即可，对应用户来说可以直接使用很方便，在当时是个新奇的玩法，这便是第一代。这个时候fbinstTool 就提供了快速定位img位置和大小功能，又在第二代
发布一段时间后取消了这个功能。

第二代
后来chenall对批处理进行了改良，可以尾续一个gz压缩的文件，用特定的命令就可以map方式加载这个gz文件，而且文件大小可以随意改变。fbinsttool同样提供了快速更换尾续文件
自动压缩等便捷功能。

第三代
chenall已经发布了新尾续方式，新版可以在批处理后面再尾续多个批处理文件和一个数据文件，数据文件可以使grub4dos能认的格式，比如cpio，iso等，
不用map就可以直接用命令访问尾续的文件，详细介绍请看http://chenall.net/post/grub4dos_initrdfs/

注：虽然grub4dos支持多种格式的数据文件，但fbinsttool只选用cpio格式，并且只尾续数据文件，也就把所有要尾续的文件都先打包成一个cpio文件后再尾续到批出后面。

fbinsttool也将添加针对第三代配套的功能

1.可以添加、删除、导出尾续的文件。
2.可以对数据文件进行gzip、lzma直接压缩和解压缩，并且保留文件名不变，也可以直接重命名文件。
3.lzma、gzip压缩过的文件不管用什么名字都显示系统关联的图标，方便归类，目前判断某个文件是否是lzma文件，目前是根据文件前面4个字符是否x5Dx0x0x40，如果是就认为是lzma文件；不知道这样是否妥当，如果你知道有更好的方法，希望能告诉我，谢谢。
4.新版fbinsttool仍然兼容第二代的尾续方式，用新版打开二代的尾续批处理可以编辑、更换尾续文件等，只要还尾续有文件fbinsttool就会按照旧的方式打开及保存；
新的批处理或者没有尾续文件的批处理，将用第三代的方式打开。

下载：
http://bbs.wuyou.net/forum.php?m ... =2182079&page=1

作者: chenall 时间: 2015-1-24 21:21

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

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

作者: jianliulin 时间: 2015-1-24 21:29
本帖最后由 jianliulin 于 2015-1-24 21:35 编辑

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

作者: 2013abcdefg 时间: 2015-1-24 21:42
好新鲜 .

作者: chenall 时间: 2015-1-24 21:58
首先一个BUG,左边添加默认的文件名有问题.

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

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

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

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

作者: jianliulin 时间: 2015-1-24 22:03
本帖最后由 jianliulin 于 2015-1-25 00:04 编辑

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

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

作者: singel 时间: 2015-1-25 01:21
发现最新版不在USB启动区发布啦{:soso_e113:}

作者: jianliulin 时间: 2015-1-25 07:37
现在可能存在bug,过几天再发布到usb板块

作者: chenall 时间: 2015-1-25 07:55

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

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

支持一个.

作者: chenall 时间: 2015-1-25 08:02
另外有没有考虑支持文件夹?

作者: 不点 时间: 2015-1-25 10:29
本帖最后由不点于 2015-1-25 10:38 编辑

lzma file format

lzma 文件格式说明

1. File Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+==================+
| Header | LZMA Compressed Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+==================+

复制代码

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

+------------+----+----+----+----+--+--+--+--+--+--+--+--+
| Properties | Dictionary Size | Uncompressed Size |
+------------+----+----+----+----+--+--+--+--+--+--+--+--+

复制代码

头部的格式，第一字节是属性字节，它的最大值是 (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-25 12:34
{:soso_e179:}{:soso_e179:}太棒了，谢谢！！！

作者: jianliulin 时间: 2015-1-25 15:42

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

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

作者: chenall 时间: 2015-1-25 15:44
嗯,确实有需要文件夹的,可以自己整,也可以直接用ISO文件

作者: jianliulin 时间: 2015-1-26 12:13
本帖最后由 jianliulin 于 2015-1-26 12:21 编辑

chenall 发表于 2015-1-25 15:44
嗯,确实有需要文件夹的,可以自己整,也可以直接用ISO文件

chenall有没有时间把你的ntboot用新的批处理重写一次

现在批处理无所不含，连外外部命令都可以直接执行，真棒！！

作者: zxw 时间: 2015-1-27 13:04
好东西，支持一个。

作者: jianliulin 时间: 2015-1-27 17:20

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

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

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

作者: zxw 时间: 2015-1-27 19:16
好，改天抽空弄一下

作者: zxw 时间: 2015-1-28 16:33

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

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

作者: x9tian 时间: 2015-1-29 11:50

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

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

作者: pseudo 时间: 2015-1-29 12:24
变量、批处理出现之前，史前续尾的样子：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=154873
fbinstTool管理批处理之前，批处理续尾一例：
http://bbs.wuyou.net/forum.php?m ... 655&pid=2435372

作者: jianliulin 时间: 2015-1-29 12:45

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

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

作者: pseudo 时间: 2015-1-31 15:42

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

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

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

作者: sunsea 时间: 2015-1-31 17:59

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

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

作者: chenall 时间: 2015-2-3 18:28
本帖最后由 chenall 于 2015-2-3 18:31 编辑

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

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

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

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

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

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

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

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

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

作者: centuryway 时间: 2015-2-4 15:02
学习了{:soso_e100:}

欢迎光临无忧启动论坛 (http://wuyou.net/)