再说最后一次！关于不再更新SkySRS的理由！

再说最后一次！关于不再更新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 
7. SVC:
8. xxService（版本1）  ->xx.sys（版本1）
10. FILE:
11. xx.sys（版本1）

复制代码

而版本为2的驱动，制作为SRS驱动后是这样的：

1. CDDB:
2. xxID-3  ->xxService 
3. xxID-4  ->xxService   
4. xxID-5  ->xxService   
5. xxID-6  ->xxService   
7. SVC:
8. xxService（版本2）  ->xx.sys（版本2） 
10. FILE:
11. 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
9. SVC:
10. xxService（版本2）  ->xx.sys（版本2） 
12. FILE:
13. xx.sys（版本2）

复制代码

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

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

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

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