再说最后一次!关于不再更新SkySRS的理由!
https://www.itiankong.net/thread-195937-1-1.html
Skyfree 发表于 2012-5-1 14:53:57
今早发帖调查了一下关于映像恢复环境,http://sky123.org/thread-195901-1-1.html,本只是为了统计倾向性,却引来了一堆对SkyIAR的牢骚。其实无独有偶,之前很多时候都有人问我为什么不更新SkySRS,而一定要推SkyIAR?我认为我已经解释的很清楚了,甚至写了5章文字用于证明SkyIAR的优势所在,以及SkySRS模式的硬伤,见:http://sky123.org/thread-178655-1-1.html。
但有些朋友甚至连“为什么不更新”都没了解一下,就一位的追问“证明不更新”的问题,我总不能一而再再而三的解释,决定写出本文,再有任何关于SkySRS为什么不更新的问题,见本文解释,不要再反复询问我,谢谢支持!
最关键的理由:SkySRS模式最大的硬伤——驱动服务、文件重叠问题
SRS驱动是由CDDB、SVC、FILE三段内容组成的(相应教程已经写了很多分,本文中不再赘述,有兴趣请运用本坛搜索功能),其中CDDB是硬件ID,是入口;SVC是服务,用于运行驱动;FILE是驱动文件,用于执行驱动。
SRS驱动执行流程:(简明)
1、系统启动时检查磁盘控制器ID是否存在于CDDB,存在则执行2,不存在则宕机
2、根据CDDB的要求,寻找SVC并启用,SVC存在则执行3,不存在则宕机
3、SVC启动,查找FILE存在性,存在则执行4,不存在则宕机
4、FILE存在则正常启动,不存在则宕机
明细流程后,那么SkySRS的硬伤是因这样的情况产生的:
某厂商的磁盘控制器,未提供一个版本可以支持所有其磁盘控制器的驱动,那么需要版本为1的驱动支持ID为1~4的磁盘控制器,需要版本为2的驱动支持ID为3~6的驱动,而版本1和版本2的SVC与FILE是相同的,会出现什么问题?
根据上例描述,版本为1的驱动,制作为SRS驱动后是这样的:
- CDDB:
- xxID-1 ->xxService
- xxID-2 ->xxService
- xxID-3 ->xxService
- xxID-4 ->xxService
- SVC:
- xxService(版本1) ->xx.sys(版本1)
- FILE:
- xx.sys(版本1)
复制代码
而版本为2的驱动,制作为SRS驱动后是这样的:
- CDDB:
- xxID-3 ->xxService
- xxID-4 ->xxService
- xxID-5 ->xxService
- xxID-6 ->xxService
- SVC:
- xxService(版本2) ->xx.sys(版本2)
- FILE:
- xx.sys(版本2)
复制代码
如果我们需要同时支持ID为1~6的所有磁盘控制器,我们该什么做?有人可能会说,那还不简单,把版本1和版本2的SRS驱动都导入不就结了??真的是这样吗?那我们先导入1后导入2,看一看实际上SRS驱动变成了什么样:
- CDDB:
- xxID-1 ->xxService
- xxID-2 ->xxService
- xxID-3 ->xxService
- xxID-4 ->xxService
- xxID-5 ->xxService
- xxID-6 ->xxService
- SVC:
- xxService(版本2) ->xx.sys(版本2)
- FILE:
- xx.sys(版本2)
复制代码
看到了吗?由于版本2和版本1的SVC、FILE同名,所以后导入的版本2理所当然的覆盖了版本1的SVC和FILE。那么,如果遇到ID为1或2的磁盘控制器,版本为1的ID竟然要是用版本为2的SVC和FILE?兼容性从何保障??稳定性又从何而来??
有部分对SRS驱动了解的人说,遇到这样的情况可以用改名法,即将SVC和FILE根据版本改名,以达到多版本并存的目的,如:
- CDDB:
- xxID-1 ->xxService1
- xxID-2 ->xxService1
- xxID-3 ->xxService2
- xxID-4 ->xxService2
- xxID-5 ->xxService2
- xxID-6 ->xxService2
- SVC:
- xxService1 ->xx1.sys
- xxService2 ->xx2.sys
- FILE:
- xx1.sysxx2.sys
复制代码
改名法的确在一定时期解决了SRS驱动SVC、FILE重名问题,这也就是为什么SRS没有早早的死亡,而带着硬伤硬挺到今天的一个原因(另一个原因是因为当年硬件类别少,不像现在这么复杂,多代主板、多代新技术)。有心的同学会发现当年INTEL的IASTOR.SYS驱动被命名为多个,如IASTOR46.SYS、IASTRO78.SYS,其实这都是根据改名法做过的。
既然改名法可以解决问题,那现在为什么不用了?原因有二:
1、目前的新驱动已经不再支持改名法,如Intel 5系列、6系列、7系列主板驱动,AMD 8系列、9系列、APU系列主板驱动。
2、Windows7对改名的驱动会认为是无认证的,无法启动。
如果改名法无效,那就意味着:
1、封装的系统,只能支持Intel5系列以下的,或支持5及5系类以上的,不能同时支持
2、封装的系统,只能支持AMD8系列以下的,或支持8及8系类以上的,不能同时支持
难道大家希望的是这样的??
简单说一句话,因为驱动改名法的失效,一个系统映像支持所有系统的时代已经过去了。无论你愿意或不愿意接受这个事实,这是客观的,无法由一个论坛一个人的力量而改变的。
而SkyIAR有效的解决了这个问题,为什么解决了这个问题?参见:http://sky123.org/thread-178655-1-1.html
这里再次重申,SkyIAR的出现,就是为了解决SkySRS不能解决的问题,是用于替代SkySRS的产物。
至于SkyIAR带来的换主板不换系统的效果,纯属附带产品(但却是个不错的附带产品),是超出SkyIAR设计本意的部分(但可行有效,甚至掩盖了其主功能的光环)。
SkyIAR的离线导入技术,是建立在完善的PE技术之上的。随着近些年PE技术的逐步完善,兼容范围逐步增大,U盘启动在维护方面的便利性逐步显现。虽然在个别计算机上可能出现PE无法启动的状况,或在少数机器上出现硬盘无法识别的问题,但这样的问题将会逐步被完善。其实退一步讲,PE和系统封装用到的SRS驱动基本类似,PE如果无法识别的硬盘,系统映像就算恢复其上,也不见得就能够启动。
SkyIAR的灵活性在于磁盘控制器驱动不位于系统映像中,便于更新和修正。系统映像不会因为磁盘控制器驱动存在缺陷而需要重新封装,新的SkyIAR出现后,旧的系统映像依旧可以使用。甚至很多古老型的经典系统映像,也可以通过SkyIAR的离线磁盘控制器驱动导入技术+SRS和PNP离线清理技术而在新机器上换发荣光。
但有些人认为SkyIAR这种模式是麻烦的,因为映像恢复一次就要导入一次IAR驱动。麻烦吗?首先,根据调查:http://sky123.org/thread-195901-1-1.html,绝大多数人会在PE下执行映像恢复工作。其次,SkyIAR拥有自动模式(见SkyIAR发布帖说明),自动模式无需人为操作,只需要短短时间即可完成IAR导入。所谓麻烦,无非是浪费时间,而相比PE启动所需的40~60秒,恢复映像后的自动化运行,也叫做麻烦?
有些朋友会说,我是部署局域网的,这种模式很麻烦,难道我要一台台计算机导入IAR驱动?公司或企业局域网内计算机硬件配置会有一定程度的相似性,SkyIAR虽然无法同时支持多种硬件,但应付相似硬件是没有什么问题的。封装前运行SkyIAR,根据你局域网内硬件类型,将不冲突的驱动直接导入系统内做成系统映像,可以当做一种精简化的固化SRS驱动使用!
至于SkySRS停止更新的理由,我想已经说明的够充分了,欢迎拍砖。
任何人,如果有解决SkySRS硬伤的方法,欢迎发帖讨论,如能解决此硬伤,我会继续更新SkySRS!
PS:说到这里个人想补充一个想法:可以做两个版本的SRS驱动,一个版本用于支持低端硬件,一个版本用于支持高端硬件,ImageX支持增量备份,不会重复占用空间,就可以做到一个系统映像中包含两个版本的系统,并带有两个版本的SRS驱动。但ImageX映像还是需要到PE下恢复,到PE下就不如使用SkyIAR方便了。
请楼下回帖人员看清楚本帖内容后再回帖,任何不明所以的无端强求一律无视。