【原创】TXTSETUP.SIF减肥和检查错误批处理TSLite V0.9（4月29日更新）

NicTense

原帖由 dvd008 于 2010-4-1 11:12 发表
pe下没用，[SourceDisksFiles] 区段可以删除

ADPTSF50.sys=1,,,,,,4_,4,1,0 就足够了

4.。。。。目的目录 drv
1 升级代码
0 全新安装代码

后面的没用，重命名只是安装版的个别文件用到

由于drv目 ...

嗯，我也觉得后面的可以删了

那这里的1，0，其作用的是1还是0

NicTense

原帖由 dvd008 于 2010-4-1 11:26 发表
我是说整个那些都可以删除
SourceDisksFiles] 区段内容可以删除

非ram只需要保留几个文件


0，0 就全部无条件的复制替换，无论有没有

升级是 原来已经有系统，已经有这个文件存在的情况下，如何处理 ...

包括drivers目录下的那些也不用指定吗？我试一下，看看会不会出问题

NicTense

测试结果，你是对的，我一直以为drivers目录下的要保留相关的项

那如果这个可以删的话，txtsetup就简单多了

非ram据说要保留的是这几个
c_936.nls=100,,,,,,,2,0,0,,1,2
kdcom.dll=100,,,,,,,2,0,0,,1,2
ntdll.dll=100,,,,,,,2,0,0,,1,2
ntoskrnl.exe=100,,,,,,,2,0,0,,1,2
setupreg.hiv=100,,,,,,,2,0,0,,1,2
vgaoem.fon=100,,,,,,,2,0,0,,1,2

我没测试过，未证实

[ 本帖最后由 NicTense 于 2010-4-1 11:51 编辑 ]

NicTense

原帖由 netwinxp 于 2010-4-1 11:50 发表
删除的话，非RAM方式可能会出问题。还有COPY方式的数值不写的话就会用缺省。

缺省是 0,0 吗

NicTense

原帖由 netwinxp 于 2010-4-1 11:55 发表
源位置那边的COPY操作默认应该是0,0，所以也可以写成,,，最后面两个表示目标位置的数字最好要写。

目标位置，默认的话是跟源位置对应的目录，如果一样的，貌似写跟不写没区别


watchdog.sys=100,,,,,,,2,0,0,,1,2

这行很奇怪，这个文件在windows里面是放在system32目录下的，而不是drivers目录下
看这样都用2应该也是

但是源文件却放在了 drivers 下

2个问题

1、这个文件干吗用的？

2、这个写法是不是应该是错的，如果放在drivers目录下，是不是红色的2应该改成4，或者把这个源文件丢到system32目录才对

NicTense

原帖由 netwinxp 于 2010-4-1 12:13 发表
watchdog.sys是防止系统崩溃的程序，写成1,2我猜测初始安装期间它可能是在system32下，装完后才移到drivers里面

问题就在于移进去之后，那个红色的2没有改成4，我这里没有毛桃的版本了，我猜测这个写法应该是源于毛桃的

而如果不改成4的话，这个文件应该是白放在里面了，因为启动后并没有在目标目录里面看到这个文件


不过这是不是证明了，这个文件实际上对pe是没用的，可以直接删了

NicTense

原帖由 dvd008 于 2010-4-1 12:32 发表
我也遇到过，可能因为 hiv里面有注册信息

SourceDisksFiles] 段内容 pe没有用到，因为
drv和里面的文件已经在目标目录了

watchdog.sys我以前尝试删除，结果蓝屏

drv有些文件txtsetup里面并没有什么， ...

赞同这个观点

实际测试结果，改为

watchdog.sys=100,,,,,,_4,2,0,0,,1,2

之后

watchdog.sys文件依然只存在于drivers目录下，并没有出现在system32目录中

也就是说，最后2个数字指定目标目录并不生效

所以我很怀疑，PE的 [SourceDisksFiles] 字段可能真的是基本上没有用的，写那么多估计都白写了

NicTense

原帖由 netwinxp 于 2010-4-1 12:41 发表
watchdog有用，而且1,,,,,,,2,0,0,,,1,2的写法不是老毛桃改错的，原版PE就是这样写的。

问题是，原版的这个文件在 system32 目录下，这样写是对的

而pe，基本上都放在了 drivers 目录下，这样写，就是错的，错的却不影响结果，所以我怀疑真的如dvd008所说，压根就不起作用

NicTense

原帖由 dvd008 于 2010-4-1 20:58 发表
非ram 需要保留几个文件， 都删除，启动时会提示，
最后找到需要的几个即可。已经测试，可以正常启动

c_936.nls=100,,,,,,,2,0,0,,1,2
kdcom.dll=100,,,,,,,2,0,0,,1,2
ntdll.dll=100,,,,,,,2,0,0,,1,2
ntoskrnl.exe=100,,,,,,,2,0,0,,1,2
setupreg.hiv=100,,,,,,,2,0,0,,1,2
vgaoem.fon=100,,,,,,,2,0,0,,1,2

跟这个列表是否有出入，如有出入，方便的话贴一下确定的名单，我没有非ram的pe,懒得重新弄一个去测试

NicTense

原帖由 dvd008 于 2010-4-2 08:25 发表
可以，如果没有，先提示ntoskrnl.exe

改造很简单，多几百k即可

光盘非ram修改方法：
UltraISO打开iso提取引导文件保存为pe.bif
winpe.is_用winrar 解压得到winpe.iso.
用UltraISO打开winpe.iso,加载pe ...

不是,我只要确定那份名单对不对,看样子是对的,就是那几个,一个不差.谢了

NicTense

呵呵，制作第一层iso的时候直接把NTDETECT.COM、SETUPLDR.BIN复制到wxpe目录下就非ram了
启动成功

有个问题一直没弄清楚

弄成ram方式除了能将最终iso弄小以外，还有没有其他的好处

NicTense

原帖由 zhaohj 于 2010-4-3 23:31 发表


ram方式速度快，非ram小内存机器用。比如64M、128M的机器。

快吗？usb1.0的话，加载ramdisk镜像在时间上是大头，所以速度主要取决于镜像大小

但是现在的usb加载很快的，硬盘更快，ram体积小，load镜像快，但是需要多解压一次，这个应该也要时间，改天有空我测试一下，如果在硬盘的话，哪个快

除了这个之外，还有没有其他原因导致从最初的非ram到后来多数用ram呢，比如兼容性之类的

[ 本帖最后由 NicTense 于 2010-4-3 23:36 编辑 ]

NicTense

原帖由 freesoft00 于 2010-4-4 00:27 发表
ram的启动后不占硬盘，可以格式化，要不锁定不让格式化。U盘的话也可以启动后拔掉U盘。

这个应该是img格式才可能存在的情况吧，貌似跟ram/非ram没关系

NicTense

原帖由 zhaohj 于 2010-4-29 10:55 发表
精简TXTSETUP.SIF，进展如何？
一直想找一个INIFILE的替代品，找不到啊。64KB的限制，外置驱动都得精简。

最近仔细研究了一下hwid的构成和优先关系之后发现

上版的算法，有些地方有点问题，这两天抽空先修改一下这个批处理，把可能出问题的部分先处理了

因为有个这样的问题存在

比如说存在A，B，C三个hwid（包含子ID）

假设 A可以替代C，本来精简掉C是没问题的，但问题就在于，如果同一个硬件，兼容ID里面既有B，又有A，那么问题就来了，如果B优先级比A高，那么A就是没用的了

上版只考虑两者的兼容关系，没有考虑程咬金的问题。。。考虑这个之后得出的结论就是CC_段由于优先级很低，最好是不精简，本身这部分也不多


但是如果要精准精简，就是确保没用的一个不留，删掉的也不会导致任何问题的话

需要判断8种情况的优先顺序，也就是对每个hwid，要判断8种情况，这个批处理有点吃不消，下次有用再改用powerbasic来处理了

[ 本帖最后由 NicTense 于 2010-4-29 11:01 编辑 ]

NicTense

原帖由 zhaohj 于 2010-4-29 11:06 发表
[SourceDisksFiles]也精简一下，只保留有用的。

驱动外置的话，[SourceDisksFiles]可以全删除，只要[HardwareIdsDatabase]，[SCSI]，[SCSI.LOAD]

[SourceDisksFiles]需要保留6行，要不改成非ramdisk会出错，这6行删除了得不偿失
如果加上这个功能可以提速，而不会减速，批处理版可以直接处理

但是只保留[HardwareIdsDatabase]，[SCSI]，[SCSI.LOAD] 这几个字段应该不行的吧 文件系统，bus层那些，包括那些files.xxx的不需要的吗

如果这样的话，我可以增加一个功能，判断如果存在 reserveditem.ini 文件的话，则只保留里面指定的段，否则不删除任何段，只做无损精简

NicTense

原帖由 zhaohj 于 2010-4-30 11:06 发表
0.9测试了一下，确实解决了以前版本中的问题。
但减肥效果也打折了。有些看来得手动。
DOS版能这样就不错了。

制作新版建议，比如A、B、C有相同的PCI\VEN_XXXX&DEV_YYYY，就要计算ABC哪个ID行最多，最多的 ...

嗯，只要不是批处理，这些就没问题
这个功能如果用批处理，可以实现，但是会使整个过程增加几分钟，而如果用编程软件，基本上不影响时间，即使用asp都不会这样

不过可能要过阵子了，有时间我就弄一下

那个HWID的问题，可以不用手工，要精确地判段，把那些容易出问题的比如CC_段也精简的话，需要对这些ID判断最多8种情况

这个批处理是吃不消的，太慢了，只能等下版有空用pb来弄了

但是像CC_段有个问题，即使判断8种格式确定没问题了，还是会影响扩展性，因为那是个越级的精简，即使当时精简后没问题，但是之后加入新的ID，里面出现程咬金的话，还是会出问题

所以凡是 CC_段的，其实都不建议越级精简（即用只有CC_一段的来替代，优先级太低了，8种情况排第8，只有前面7种都没有指定驱动才会被用到，但是有些公司偏偏喜欢把ide,ahci,raid等都用一样的主id

[ 本帖最后由 NicTense 于 2010-4-30 11:51 编辑 ]