Say the last time! About the reason for not updating Skysrs!

Say the last time! About the reason for not updating Skysrs!

Https://www.itiankong.net/thread-195937-1-1.html

Skyfree published in 2012-5-1 14:53:57

posted this morning to investigate the image recovery environment, http://sky123.org/thread-195901-1-1.html, this is just for statistical bias, but drew a bunch of skyiar complaints. In fact, a lot of times before people asked me why not update Skysrs, and must push Skyiar? I think I have explained very clearly, and even wrote 5 chapters to prove the advantages of Skyiar, as well as the SKYSRS model of the mishap, see: http://sky123.org/thread-178655-1-1.html.

But some friends even "why not update" did not understand, on the question of a "proof not to update", I can not again again explanation, decided to write this article, and then any questions about Skysrs why not update, see this article explain, do not ask me repeatedly, thank you for your support!

Most critical reason: Skysrs mode the biggest mishap--drive service, file overlap Problem

srs driver is CDDB, SVC, File Three paragraph content (the corresponding tutorial has written a lot of points, this article will not repeat, interested in using this altar search function), which CDDB is the hardware ID, is the entry ; svc is a service that is used to run the driver ; file is the driver file that is used to perform the driver .

SRS driver Execution Process: (concise)
1, System startup check if the disk controller ID exists in CDDB, there is execution 2, no downtime
2, according to the requirements of CDDB, find the SVC and enable, the SVC exists to execute 3, Does not exist then the outage
3, The SVC starts, looks for the file existence, the existence then executes 4, does not exist then the outage
4, the file existence is normal startup, does not exist the downtime

The detailed flow, then Skysrs's mishap is because of this situation to produce:
A manufacturer's disk controller, does not provide a version can support all its disk controller driver, then need version 1 driver support ID 1~4 disk controller, need version 2 driver support ID 3~6 driver, and version 1 and version 2 of the SVC and file is the same, what happens?

as described in the previous example, a driver with version 1 is created as an SRS driver:

1. CDDB:
2. XxID-1->xxservice
3. XxID-2->xxservice
4. XxID-3->xxservice
5. XxID-4->xxservice
7. Svc:
8. Xxservice (version 1)->xx.sys (version 1)
10. FILE:
11. Xx.sys (version 1)

Copy Code

And the version of the 2 driver, produced for the SRS driver is this:

1. CDDB:
2. XxID-3->xxservice
3. XxID-4->xxservice
4. XxID-5->xxservice
5. XxID-6->xxservice
7. Svc:
8. Xxservice (version 2)->xx.sys (version 2)
10. FILE:
11. Xx.sys (version 2)

Copy Code

What do we do if we need to support all disk controllers with ID 1~6 at the same time? One might say that it is not easy to import version 1 and version 2 of the SRS driver is not a knot?? Is that really the case? Let's import 1 and then import 2, and take a look at what the SRS driver actually turns into:

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 (version 2)->xx.sys (version 2)
12. FILE:
13. Xx.sys (version 2)

Copy Code

Did you see it? Because of the same name as the SVC and file of version 2 and version 1, the post-import version 2 would, of course, overwrite the SVC and file of version 1. So, if you encounter a disk controller with ID 1 or 2, the ID of version 1 should be used with the version 2 Svc and file? How to protect the compatibility?? Where does stability come from?

Some of the SRS drivers understand that the situation can be changed by renaming, the SVC and file will be renamed according to the version, in order to achieve multi-version coexistence purposes, such as:

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

Copy Code

Renaming method Indeed in a certain period of time to solve the SRS Drive Svc, file name problem, which is why the SRS did not die early, and with the mishap stiff to today's one reason (another reason is because of the hardware category is less, unlike now so complex, multi-generation motherboard, multi-generational new technology). The heart of the students will find that the Intel Iastor.sys Drive was named multiple, such as Iastor46.sys, IASTRO78. SYS, which is actually done by renaming the law.

Since the renaming method can solve the problem, why not now? There are two reasons:
1, the current new driver has no longer support renaming method, such as the Intel 5 Series, 6 series, 7 Series motherboard driver, AMD 8 Series, 9 Series, APU Series motherboard driver.
2, Windows7 to the name of the driver will be considered to be non-certified, unable to start.

If the renaming method is invalid, it means:
1, the package system, can only support the INTEL5 series below, or support 5 and 5 series above, cannot simultaneously support
2, the package system, can only support the AMD8 series below, or support 8 and 8 series above, cannot simultaneously support
Is this what we all want?

To put it simply, the time has passed for a system image to support all systems because of the failure of the driver renaming method. Whether you are willing or unwilling to accept this fact, this is objective and cannot be changed by the power of a forum person.

and Skyiar solves this problem effectively, why solve this problem? See also:http://sky123.org/thread-178655-1-1.html

Here again, the emergence of Skyiar, is to solve the problem Skysrs can not solve, is to replace the SKYSRS product.
As for the Skyiar brought by the motherboard does not change the effect of the system, purely incidental products (but it is a good companion product), is beyond the original design of the Skyiar part (but feasible and effective, even masking the aura of its main function).

Skyiar's off-line import technology is built on the perfect PE technology. With the gradual improvement of PE technology in recent years, the scope of compatibility gradually increased, U disk startup in the maintenance of convenience gradually appeared. Although there may be situations where PE cannot be started on individual computers, or if the hard drive is not recognized on a few machines, the problem will be gradually improved. In fact, the PE and the System package for the SRS drive is basically similar to PE, if the hard disk is not recognized, the system image even if it is restored, it is not necessarily able to start.

The flexibility of the Skyiar is that the disk controller driver is not in the system image and is easy to update and remediate. The system image does not need to be re-encapsulated because the disk controller driver is defective, and the old system image can still be used after the new Skyiar appears. Even many ancient classic system images can be renewed on new machines through Skyiar's offline disk controller-driven import technology +SRS and PnP off-line cleanup technology.

But some people think that skyiar this mode is troublesome, because the image recovery will be imported once the IAR driver. Are you in trouble? First, according to the survey: http://sky123.org/thread-195901-1-1.html, the vast majority of people perform image recovery work under PE. Second, Skyiar has automatic mode (see Skyiar post description), automatic mode without human action, only a short time to complete the IAR import. The so-called trouble, is nothing more than a waste of time, and compared to the PE boot required 40-60 seconds, restore the image after the automated operation, also known as trouble?

Some friends will say, I am deploying LAN, this mode is very troublesome, I want a computer to import IAR driver? There is a degree of similarity in the computer hardware configuration of the company or enterprise LAN, although Skyiar cannot support multiple hardware at the same time, there is no problem in dealing with similar hardware. Before encapsulation run Skyiar, according to your LAN hardware type, the non-conflicting drive directly into the system into a system image, can be used as a streamlined curing SRS drive!

As for the reason for Skysrs to stop updating, I think I have already explained enough, welcome to shoot bricks.

Anyone, if there is a way to solve Skysrs mishap, welcome post discussion, if you can resolve this mishap, I will continue to update skysrs!

PS: Speaking of Here, I would like to add an idea: You can do two versions of the SRS driver, a version to support low-end hardware, a version to support high-end hardware, ImageX support incremental backup, do not take up space, you can do a system image contains two versions of the system, And with two versions of the SRS driver. However, ImageX image still needs to be recovered under PE, it is not as convenient to use Skyiar under PE.

Please reply staff downstairs to see clearly this post content and then reply, any unknown so unwarranted forced to ignore.

Say the last time! About the reason for not updating Skysrs!