再说最后一次!关于不再更新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驱动后是这样的:

  1. CDDB:
  2. xxID-1  ->xxService
  3. xxID-2  ->xxService
  4. xxID-3  ->xxService
  5. xxID-4  ->xxService
  6. SVC:
  7. xxService(版本1)  ->xx.sys(版本1)
  8. FILE:
  9. xx.sys(版本1)

复制代码

而版本为2的驱动,制作为SRS驱动后是这样的:

  1. CDDB:
  2. xxID-3  ->xxService
  3. xxID-4  ->xxService
  4. xxID-5  ->xxService
  5. xxID-6  ->xxService
  6. SVC:
  7. xxService(版本2)  ->xx.sys(版本2)
  8. FILE:
  9. xx.sys(版本2)

复制代码

如果我们需要同时支持ID为1~6的所有磁盘控制器,我们该什么做?有人可能会说,那还不简单,把版本1和版本2的SRS驱动都导入不就结了??真的是这样吗?那我们先导入1后导入2,看一看实际上SRS驱动变成了什么样:

  1. CDDB:
  2. xxID-1  ->xxService
  3. xxID-2  ->xxService
  4. xxID-3  ->xxService
  5. xxID-4  ->xxService
  6. xxID-5  ->xxService
  7. xxID-6  ->xxService
  8. SVC:
  9. xxService(版本2)  ->xx.sys(版本2)
  10. FILE:
  11. xx.sys(版本2)

复制代码

看到了吗?由于版本2和版本1的SVC、FILE同名,所以后导入的版本2理所当然的覆盖了版本1的SVC和FILE。那么,如果遇到ID为1或2的磁盘控制器,版本为1的ID竟然要是用版本为2的SVC和FILE?兼容性从何保障??稳定性又从何而来??

有部分对SRS驱动了解的人说,遇到这样的情况可以用改名法,即将SVC和FILE根据版本改名,以达到多版本并存的目的,如:

  1. CDDB:
  2. xxID-1  ->xxService1
  3. xxID-2  ->xxService1
  4. xxID-3  ->xxService2
  5. xxID-4  ->xxService2
  6. xxID-5  ->xxService2
  7. xxID-6  ->xxService2
  8. SVC:
  9. xxService1  ->xx1.sys
  10. xxService2  ->xx2.sys
  11. FILE:
  12. 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方便了。

请楼下回帖人员看清楚本帖内容后再回帖,任何不明所以的无端强求一律无视。

04-22 19:40