无忧启动论坛
标题: 五套启动策略实战UD被识别为USB-ZIP启动(下午在添加一种) [打印本页]
作者: chiannet 时间: 2011-11-6 06:40
标题: 五套启动策略实战UD被识别为USB-ZIP启动(下午在添加一种)
测试老机器:某型号精英主板,AMD 3400+ CPU,2GB RAM, UD被稳稳识别为USB-ZIP方式。
关于计时:
计时器:nokia手机秒表;
开始:在菜单处,左手按下计时开始,同时右手按下回车键,启动native PE选单,开始启动PE;
结束:到windows正在初始化出现(到这个地方,就是二级内核已成功挂载,权利移交PECMD.exe,从这往后都是windowsPE加载了驱动了);
软件环境:
WINPE.ISO(二级内核)、NATIVE.ISO(native方式的03PE一级内核)保持不动;
只改grldr(20111103) buldr 和native(20111103 grldr改名而来)内置菜单。
==================================================================================
方案一
要点:用buldr且没用--mem参数
耗时:0:01:05:49
(ud)/grldr
- title Native 03PE
- calc *0x8280 || chainloader (ud)/AXPE/BULDR
- calc *0x82b8 && calc *0x82b9&0xff || chainloader (ud)/AXPE/BULDR
- (ud)/AXPE/SRS/SRSF6N (ud)/AXPE/SRS
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map (ud)/AXPE/NATIVE.ISO (0xff)
- map --hook
- chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码(ud)/AXPE/BULDR
-
- map --set (boot)/AXPE/NATIVE.ISO (cd127)
- ntldr (boot)/AXPE/native
- boot
复制代码(ud)/AXPE/native
- timeout 0
- default 0
- title Native PE @ SRSF6N
- (ud)/AXPE/SRS/SRSF6N (ud)/AXPE/SRS
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map --hook
- chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码
==================================================================================
方案二:
要点:用buldr且带--mem参数
耗时0:01:05:10
(ud)/grldr- title Native 03PE
- calc *0x8280 || chainloader (ud)/AXPE/BULDR
- calc *0x82b8 && calc *0x82b9&0xff || chainloader (ud)/AXPE/BULDR
- (ud)/AXPE/SRS/SRSF6N (ud)/AXPE/SRS
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map (ud)/AXPE/NATIVE.ISO (0xff)
- map --hook
- chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码 (ud)/AXPE/BULDR- map --mem --set (boot)/AXPE/NATIVE.ISO (cd127)
- ntldr (boot)/AXPE/native
- boot
复制代码 (ud)/AXPE/native- timeout 0
- default 0
- title Native PE @ SRSF6N
- (ud)/AXPE/SRS/SRSF6N (ud)/AXPE/SRS
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map --hook
- chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码==================================================================================
方案三:
要点,只用grldr map,且带--mem参数
耗时0:00:44:66
(UD)/grldr
- title Native 03PE
- calc *0x8280 || set mem=yes
- calc *0x82b8 && calc *0x82b9&0xff || set mem=yes
- (ud)/AXPE/SRS/SRSF6N (ud)/AXPE/SRS
- map (ud)/AXPE/WINPE.ISO (0xfa)
- if %mem%==yes && map --mem (ud)/AXPE/NATIVE.ISO (0xff) ! map (ud)/AXPE/NATIVE.ISO (0xff)
- map --hook
- chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码
==================================================================================
方案四:
要点,用grldr map,且不带--mem参数
耗时 0:01:05:34
(UD)/grldr
- title Native 03PE
- # calc *0x8280 || set mem=yes
- # calc *0x82b8 && calc *0x82b9&0xff || set mem=yes
- (ud)/AXPE/SRS/SRSF6N (ud)/AXPE/SRS
- map (ud)/AXPE/WINPE.ISO (0xfa)
- if %mem%==yes && map --mem (ud)/AXPE/NATIVE.ISO (0xff) ! map (ud)/AXPE/NATIVE.ISO (0xff)
- map --hook
- chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码
=======================================================
方案五:
要点,用buldr map
耗时 0:01:05:17
(ud)/GRLDR:
- title Native 03PE
- chainloader (ud)/AXPE/BULDR
复制代码
(ud)/AXPE/BULDR:
- map --set (boot)/AXPE/NATIVE.ISO (cd127)
- cdload --image=0 ($root)
- ntldr (boot)/AXPE/native
- boot
复制代码
(ud)/AXPE/native:
- timeout 0
- default 0
- title Native PE
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map --hook
- chainloader (0xff) || chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码
==================================================================================
在该机器上方案三胜出!
其他四种忽略计量等误差,居然全相同?!
该测试结果仅对该机有效,请勿泛推。
[ 本帖最后由 chiannet 于 2011-11-6 16:28 编辑 ]
作者: 2011laolin 时间: 2011-11-6 08:05
呵呵,楼主辛苦了。您的UD版很好用,特别是能换桌面,这别人是没有的。看来用buldr且没用--mem参数方案并没有比只用grldr map且带--mem参数的方案快呀。我还以为计时是要从按下回车键启动native PE选单开始到出现桌面为止呢。
作者: snbxeon 时间: 2011-11-6 08:37
呵呵,秒表计算,楼主辛苦啦~~~
作者: hotdll 时间: 2011-11-6 11:11
标题: 回复 #2 2011laolin 的帖子
楼主的结果我想当的不赞成
1、PE的启动时间是从按菜单到桌面,而不是初始化。
2、您没有说明你的机器是USB1.1还是USB2.0,识别U盘的情况。
3、您的测试,并没有用到burg的功能。
作者: chiannet 时间: 2011-11-6 12:48
标题: 回复 #4 hotdll 的帖子
赞不赞同不要紧,事实摆在那里了
1、所有的起终结时间截取点是一致的,PE启动的快慢关键点就是这一段时间。之后的时间消耗各版本也是一致的,因为之后都是加载PE已经了USB驱动,比较没有含义了,我也没有说那些时间是完整PE启动的时间。
2、“UD被稳稳识别为USB-ZIP方式”,开头就声明了的。
3、方式一、方式二可以明确地看到buldr执行的过程。
[ 本帖最后由 chiannet 于 2011-11-6 12:52 编辑 ]
作者: chiannet 时间: 2011-11-6 12:50
再次声明:
在该机器上方案三胜出!
其他三种忽略误差,全相同。
此结论仅对该机器而言,并不适宜推广开。
作者: hotdll 时间: 2011-11-6 12:51
标题: 回复 #5 chiannet 的帖子
map --set (boot)/AXPE/NATIVE.ISO (cd127)
ntldr (boot)/AXPE/native
boot
这里有错误。你并没有使用burg启动该 native.iso
你还是不挑明白原理。其实我已经说的很清楚了,是用burg启动一级内核,用grldr仿真二级内核。
您的代码很明显的是用grldr启动一级内核。
作者: hotdll 时间: 2011-11-6 12:53
标题: 回复 #6 chiannet 的帖子
讨论帖子变结论了?
哪算了,就当我路过。。。。
作者: chiannet 时间: 2011-11-6 13:11
标题: 回复 #7 hotdll 的帖子
这个实验 说明 buldr 的map及map--mem与grldr map 三者效能上没有什么很大差距。
以上这四个实验是今天早上做的。
至于用burg直接启动一级内核(native.iso)的方式,昨天也是做了测试的,只是当时没计时。只是感官上也没比第三种快。因没数量上的精准度计,就没拿出来讨论了。今晚可以再补充二个测试的。
作者: chiannet 时间: 2011-11-6 14:16
TEST1
(ud)/GRLDR:- title Native 03PE
- chainloader (ud)/AXPE/BULDR
复制代码 (ud)/AXPE/BULDR:- map --set (boot)/AXPE/NATIVE.ISO (cd127)
- cdload --image=0 ($root)
- ntldr (boot)/AXPE/native
- boot
复制代码 (ud)/AXPE/native:-
- timeout 0
- default 0
- title Native PE
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map --hook
- chainloader (0xff) || chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码 这样子可以启动NATIVE.ISO 。
TEST2
(ud)/GRLDR:-
- title Native 03PE
- chainloader (ud)/AXPE/BULDR:
复制代码 (ud)/AXPE/BULDR- map --set (boot)/AXPE/NATIVE.ISO (cd127)
- cdload --image=0 ($root)
- # ntldr (boot)/AXPE/native
- boot
复制代码 这样子可以启动NATIVE.ISO
TEST3
(ud)/GRLDR:- title Native 03PE
- chainloader (ud)/AXPE/BULDR
复制代码 (ud)/AXPE/BULDR:- map --set (boot)/AXPE/NATIVE.ISO (cd127)
- cdload --image=0 ($root)
- ntldr (boot)/AXPE/native
- boot
复制代码 (ud)/AXPE/native:-
- timeout 0
- default 0
- title Native PE
- map (ud)/AXPE/WINPE.ISO (0xfa)
- map --hook
- # chainloader (0xff) || chainloader (0xff)/AXPE/SETUPLDR.BIN
复制代码 这样子无法启动NATIVE.ISO
这三个测试说明buldr并不能同时启动两路?TEST1里的NATIVE.ISO应该还是属于从grldr启动的,也就是说“cdload --image=0 ($root)”貌似没起作用,但单独只存在cdload,后面没有NTLDR命令时,该语句可启动NATIVE.ISO。
[ 本帖最后由 chiannet 于 2011-11-6 14:24 编辑 ]
作者: 幸运的草 时间: 2011-11-6 18:17
楼主可以再做个测试:
以普通PE,非NATIVE版的那种,ZIP盘, map 无参数时启动PE进桌面,或者到WINDOWS启动时。时间点自定,就以杏雨梨去A版中的那个PE为准,看从BURG引导与G4D引导各自的时间为多少?
native的一级内核只有4M多一点,在个别机上是一闪而过的。没多少意义。
作者: xianglang 时间: 2011-11-6 18:32
我觉得吧,如果从按下菜单选项到进入桌面这样计算,肯定是 map --mem 比 map 要快:U盘(读卡器+SD卡等)都是读大文件比小文件快,因此 map --mem 加载镜像到内存之后,PE的所有大、小文件都是直接从内存读取,将会省下不少时间;而 map 加载镜像,PE的所有大、小文件都是直接从U盘读取,速度肯定慢不少,而且它所需的时间,也肯定比直接 map --mem 加载一个大ISO文件要多得多。而且即使进入了桌面之后,map --mem 方式也肯定要比 map 方式快得多。
作者: xianglang 时间: 2011-11-6 18:35
在加载成功的安全性上来说,PE内核所有文件都放进同一个ISO或者IMG里的PE方式,也肯定要比0PE、NATIVE等分级这种方式,理论上要高得多,因为分级这种方式,转换环节越多,出错的可能越大,因此不成功的可能就越大。
作者: 幸运的草 时间: 2011-11-6 18:38
根据机器的不同,有的机BIOS中自带USB2.0驱动,这时在g4d下zip盘map 时速度很快,而大部分老机则是2.0的接口,而bios没有自带2.0驱动,这时zip盘map时的速度非常的慢,加载一个30M左右的内核,启动时间(进桌面)一般要十几分钟,而同机同盘,HDD时可能只能两分之内完成启动。
但如果加参数--mem时,启动时间也非常快。但有一点有的机会出现内存冲突造成蓝屏,而且对于ISO体积的大小与内存大小有密切关系,如果小内存大体积的ISO,加参数就没法启动了。
native版的出现恰恰就是为了解决G4D的这一缺陷,提高了PE的启动速度。当然也可以使用加速器来提高PE的启动速度。
每种方案都有其适用范围,比如,有的机使用加速器会死机,有的USB键鼠在用加速器后造成无法使用。
而burg则没有G4D的这种缺陷,ZIP,map时的速度与hdd的map的速度没有什么区别。
而加参数--mem从理论上说无论是G4D还是BURG,都是要比不加参数上要快一点,但不是绝对的,与iso的体积有关。体积越小,不加参数有可能反而快一点,体积越大,加参数则会快一点。
用c大的说来说,不要乱比。乱比没有意义。
-------------------------------------------------------------------------------------------
只能对比zip盘,在g4d下,不加参数map ISO时与在burg下map iso时,同一个盘,同一台机,同一样PE内核,启动时间。除此之外,G4D都是很优秀的,不比BURG差。
另外,burg还有一个G4D不如的功能,就是map 时不用文件连续存放,且不用--hook,直接生效。
[ 本帖最后由 幸运的草 于 2011-11-6 18:40 编辑 ]
作者: 幸运的草 时间: 2011-11-6 18:59
前面说了,因为native一级内核较小,再由于burg本身没有速度差异,而在ZIP时采用变通调用BURG引导一级内核的方法,加参数调用一级内核与不带参数调用,恰恰省出了向内存加载的一段时间,反而是不加参数会稍快一点(当然并不是所有机如此),因为加参数是由burg负责向内存加载,GRLDR负责启动,而不加参数时是burg负责启动一级内核。区别仅在于此,那句cdload就是burg启动仿真光驱的命令。
========================================
尺有所短,寸有所长。专机有专方案,每一种方案都不可能对每一台机适用,提出该方案可能会适合一部分老机,个人根据自己的情况灵活运用,选适合自己的是最聪明的人。
本人的机测试,以杏雨的那个PE,ZIP盘,在g4d下map时进桌面要14分钟,用burg引导map 时1分50秒。
当然加参数及HDD时速度是很快的,由于无对比性,在此忽略........
tangope native版 用借用burg交替引导,有--mem参数时,zip 盘map,进桌面要40秒,而不加参数时25秒。 SKYPE native版,用借用burg交替引导,有--mem参数时,zip 盘map,进桌面要45秒,而不加参数时40秒。
而hotdll的测试结果也基本相同,当然这种测试无任何意义。但结果对我们使用有很大的意义。
作者: chiannet 时间: 2011-11-6 19:45
标题: 回复 #15 幸运的草 的帖子
所以说即便对各种不同老机器机器,貌似暂时没有通用的加速引导办法。更多可能要靠使用者经验取舍。
比如你提到你的机子就适宜g4d-burg-g4d轮转,我碰到的这台“鸟机”反倒是直接G4d map --mem快。
还有,10楼的3个测试你看了没?
作者: 快雪时晴 时间: 2011-11-6 19:48
calc *0x8280 || set mem=yes
calc *0x82b8 && calc *0x82b9&0xff || set mem=yes
0x8280我知道是代表启动设备,0表示软盘,23表示ud
0x82b8和0x82b9代表什么,最近老见着,不大明白,也找不到出处,但猜测似乎也是判断hdd用的
为什么要两句(行)才能最终判断是否u盘zip启动?
作者: 幸运的草 时间: 2011-11-6 20:30
原帖由 chiannet 于 2011-11-6 14:16 发表
TEST1
(ud)/GRLDR:title Native 03PE
chainloader (ud)/AXPE/BULDR(ud)/AXPE/BULDR:map --set (boot)/AXPE/NATIVE.ISO (cd127)
cdload --image=0 ($root)
ntldr (boot)/AXPE/native
boot(ud)/AXPE/na ...
你说的不会启动,是因为你忽视了一个问题,因为是组合启动,你把chainloader (0xff)这条命令给禁用了,burg已经将控制权交给了grldr,由于grldr 达不到启动条件,所以BURG也就不启动了。这就是HOTDLL说的同时执行。
你这个着,你把buldr 菜单中红色的部分禁用,单独用BURG启动native.iso,看看能否启动?你再把蓝色部分禁用,看看cdload起没有作用。
map --set (boot)/axpe/native.iso (cd127)
cdload --image=0 ($root)
#ntldr (boot)/axpe/native
boot
感觉你真的对BURG不了解。你的测试不能说明问题。(针对你的测试言),有的BURG根本就没起作用。
因为你忽略了二级内核的加载。
[ 本帖最后由 幸运的草 于 2011-11-6 20:37 编辑 ]
作者: chiannet 时间: 2011-11-6 20:36
标题: 回复 #18 幸运的草 的帖子
TEST 2就是你说的禁红色部分。
作者: chiannet 时间: 2011-11-6 20:40
标题: 回复 #18 幸运的草 的帖子
所以我觉得从TEST1到TEST3这三个测试说明:
TEST1的结果实质还是GRLDR启动的native.iso,并非cdload --image=0这句的效能。
作者: 幸运的草 时间: 2011-11-6 20:53
标题: 回复 #20 chiannet 的帖子
我不是说了,你把红色的部分禁用,BURG就不会将控制权转交GRLDR了,你看能否启动。再将蓝色代码禁用,再看能否启动。就知道CDLOAD起没起作用。
如果不起作用,那BURG就不用引导ISO了。
动手试一下,再下定论。
好吧,没什么意思,用P大的话说,只要有一台机成功,那就是成功了,其他可以无视。至少目前不是一台机有效果吧。
以你的一台机的测试就下定论,未免有点草率。
作者: chiannet 时间: 2011-11-6 21:01
标题: 回复 #21 幸运的草 的帖子
晕,怎么就没看明白呢?难道表述的不够清晰?
1楼方案一不就是你说的蓝色代码禁用?
10楼TEST2不就是你说的红色的部分禁用?
综合这些测试,难道还不能说明CDLOAD在10楼TEST1里(或者说1楼方案五)的确没起作用(表现在启动速度上也没有什么)?
[ 本帖最后由 chiannet 于 2011-11-6 21:06 编辑 ]
作者: chiannet 时间: 2011-11-6 21:10
标题: 回复 #21 幸运的草 的帖子
再说我也没下什么结论呀?
我只是说,按照10楼TEST1里(或者说1楼方案五)这种写法
貌似并不能达到
1、用cdload --image=0 (map255) 启动一级内核
2、在burg启动一级内核的时候,调用grldr仿真二级内核的ISO镜像。
实质是并非BURG在启动一级内核,最终还是GRLDR在引导启动一级内核吧?
作者: busn 时间: 2011-11-7 01:44
这种技术性的讨论才是推动进步的力量。
作者: jwuskf 时间: 2011-11-7 02:36
最近看了你们的贴子说 buldr 和 grub 交替使用会快点? 真复杂,想不明白啊!
我个人喜欢把问题简单化,如果不是为了全内置UD,把二级内核扔到可见分区,
问题就没那么复杂了吧,复杂的问题不仅难解决,还会带来不稳定,双显卡蓝屏的问题还没解决呢。
有了Native,进入PE已经够快的了,就不要再为那么一点点速度计较了吧。
如果有另一种方法可以保护可见分区的部份文件就好了,这样的话放不放在UD内并不重要吧。
作者: rockrock99 时间: 2011-11-7 08:46
标题: 回复 #25 jwuskf 的帖子
我是从来不用UD的,保护文件只需买个带写保护开关的U盘,例如朗科的U208(速度不怎么快)
作者: 快雪时晴 时间: 2011-11-7 09:52
标题: 自说自话
原帖由 快雪时晴 于 2011-11-6 19:48 发表
calc *0x8280 || set mem=yes
calc *0x82b8 && calc *0x82b9&0xff || set mem=yes
0x8280我知道是代表启动设备,0表示软盘,23表示ud
0x82b8和0x82b9代表什么,最近老见着,不大明白,也找不到出处,但猜测 ...
看来问题够白的,自己不完全实验了下
如果u盘识别为hd
则cat --hex (md)0x41+1可以看到0x8280 82b8 82b9分别是:0x80 3F 80
如果识别为zip的话
:0x00 3F 00
大概知道咋回事了
作者: jwuskf 时间: 2011-11-7 12:02
标题: 回复 #26 rockrock99 的帖子
如果UD能再建一个区域可读不可写的那就完美了。
作者: 2011willinguo 时间: 2012-2-18 08:17
标题: 回复 #1 chiannet 的帖子
这个是怎么个意思啊
没看明白
作者: pseudo 时间: 2012-2-18 22:52
谢谢楼上顶起此帖。
楼主有测试环境,有空请帮测试一下。
无论是否usb-zip,纯g4d的半解开(并回车)方式:
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=205491
应该不会明显慢。跟借助burg的方式应该相当。
借助burg的方式:
0PE.ISO文件在ud根目录(或按半解开部署),buldr文件在ud根目录,burg菜单:-
- set timeout=0
- menuentry " 0PE.ISO " --class windows {
- search -s -f /0PE.ISO
- map --set /0PE.ISO (cd96)
- cdload --image=0 ($root)
- }
复制代码 fbinst菜单略。
可以弄个有停留的fbinst菜单,从选fbinst菜单项开始计时,直到出现桌面“我的电脑”图标。
这样计时比较符合用户需求。如果中途有按键、选菜单项之类的操作,可适当扣除操作所花时间,使其相当于全自动运行。
测试目的:
1、验证纯g4d方案不会明显慢。
2、验证此PE的U启不明显慢于其它任何PE1.x——不怕慢,只要不明显慢就够了。
请勿将此PE与其它具体PE做优劣对比。如果发现明显慢,请详细告知以便改进。
[ 本帖最后由 pseudo 于 2012-2-18 23:02 编辑 ]
作者: 2011ryoohki 时间: 2012-2-19 03:04
buldr 和 grldr 有什么区别啊 ?
作者: hotdll 时间: 2012-4-10 13:07
原帖由 chiannet 于 2011-11-6 06:40 发表
测试老机器:某型号精英主板,AMD 3400+ CPU,2GB RAM, UD被稳稳识别为USB-ZIP方式。
关于计时:计时器:nokia手机秒表;
开始:在菜单处,左手按下计时开始,同时右手按下回车键,启动native PE选单,开始启 ...
我今天无意中发现。
你测试的boot有问题。。。。。。。。。
作者: chiannet 时间: 2012-4-10 13:33
标题: 回复 #32 hotdll 的帖子
呵呵,正好半年过去了。真快。
我的确是不知道buldr,也不想花时间在上面了。只是但是看到论坛传闻buldr的 map 高效率,忍不住试一下,但是遗憾,没有发现宝。
boot有问题?是何意,具体指测试几?应该怎么修改?
作者: Plantsoot 时间: 2012-4-10 13:34
标题: 回复 #33 chiannet 的帖子
burg有一个地方目前grub4dos没办法超越,可以map不连续的ISO,不加--mem。
希望我没记错。
作者: hotdll 时间: 2012-4-10 15:01
原帖由 chiannet 于 2012-4-10 13:33 发表
呵呵,正好半年过去了。真快。
我的确是不知道buldr,也不想花时间在上面了。只是但是看到论坛传闻buldr的 map 高效率,忍不住试一下,但是遗憾,没有发现宝。
boot有问题?是何意,具体指测试几?应该怎 ...
你调用burg后,没有boot命令,所以执行的还是grldr
作者: chiannet 时间: 2012-4-10 15:15
标题: 回复 #35 hotdll 的帖子
你看测试一与测试二的代码,buldr内的菜单明明是有boot命令的!
作者: chiannet 时间: 2012-4-10 15:20
此问题到此了结,本人无意继续深挖。没有条件、也不会再去测试。反正当时的测试环境及过程我都在详细地在帖子里写了,有兴趣的朋友看帖研究。
欢迎光临 无忧启动论坛 (http://wuyou.net./) |
Powered by Discuz! X3.3 |