The official definition of the life cycle of software is given. However, in actual situations, the maintenance work of old software and the actual needs presented by users are often particularly prone to the kind of "delay" that can cause confusion.
Software life cycle and vendor support strategy
According to the relevant theoretical concepts of software engineering, such a software will definitely go through the definition stage from the beginning until it is completely abandoned, followed by the development stage, then the testing stage, then the release stage, and finally maintenance, etc. These are all complete stages. Microsoft has set a clear life cycle support strategy for the products it produces. Mainstream support for Office 2010 ended in 2015, and subsequent extended support for this software is scheduled to be officially terminated on October 13, 2020. This usually means that Microsoft will no longer provide technical support including security updates from then on.
However, in actual operations, this so-called "termination" situation is sometimes not a clean cut. For an office suite that accommodates a large number of enterprise users, in order to completely stop the service, it is necessary to think about the stability of the deployed system and the transition period of migration. Although there is a lack of official explanation, in large organizations, remedial actions for specific serious vulnerabilities may be provided on a limited basis in a non-public form after the deadline, in order to take care of customers who have not yet upgraded.
Continued user demand for legacy software
Even if the new version of the software is more powerful in terms of functionality, some users still rely on the old version for a long time due to hardware conditions, system compatibility or usage habits. For example, some internal enterprise-specific systems may only be adapted to specific interfaces of Office 2010, and the upgrade cost is extremely high. There are also many individual users who feel that the old version can fully meet their daily needs and is more compatible with older Windows XP or Windows 7 systems.
A persistent need has spawned a vibrant community. Users will share various methods to enable old versions of software to continue to run on new era operating systems. They even use methods such as integrating update packages and modifying configuration files to create "integrated installation images" by themselves, trying their best to extend the original life of the software after the end of official support.
Principles of production and streamlining of integrated images
The main purpose of the integrated installation image produced by the user is not to reduce functions, but to optimize the installation process. The traditional installation method requires you to complete the installation of basic software first, and then install dozens of subsequent update patches one by one. The steps are complicated and time-consuming. The integrated image will integrate all update patches up to a certain point in time, that is, .msp and .xml files, directly into the installation source file.
The benefits of this are extremely significant. After the user completes the installation, the software is directly displayed in the "latest state" and does not need to go through a long patching process. This not only saves the time required for installation, but also avoids the failure of individual updates due to network problems. This idea is similar to the "Click-to-Run" installation technology introduced by Microsoft later, and its purpose is to provide an integrated deployment experience.
Size reduction and system compatibility trade-off
For producers, in order to reduce the size of image files, they usually perform streamlining operations. A commonly used approach is to retain only specific language pack category files that are essential for installation, and remove resources needed for other languages. At the same time, with the help of packaging related technologies, duplicate files existing in the installation package are removed to further achieve the effect of compressing the volume. All these operations are carried out under the premise of making every effort to ensure that the functions of the core of the program remain intact.
However, while simplicity creates convenience, it also comes with a price. The most direct impact is that such integrated updates cannot be uninstalled or rolled back separately through the control panel. If an update causes compatibility issues, users have no way to remove it. In addition, such integrated versions can no longer receive or install new updates released by the official, and the system update push function will also be invalid.
Adaptation and cracking on old operating systems
Putting new software patches to run on old systems is a difficult challenge. For Windows XP, Microsoft has long since stopped supporting it. Many software patches designed for Windows 7 and above systems may have internal functions that cannot be supported by XP. If installed directly, the software will not start. The most common error is directly linked to the core mso.dll file.
In the community, technology enthusiasts often try to crack it. One method is to first find a specific file, such as mso.dll , and then replace it with a modified one with a new patch, in order to try to bypass system detection. There is another more thorough method, which is to directly delete the update package files that clearly do not support the XP system in the integrated installation image, and then manually install the old but compatible patches after the installation is complete. However, although these methods may be successful, they often make the software unstable and lead to various unpredictable errors.
Risk considerations and rational use recommendations
There are multiple risks in using software that has stopped supporting software and third-party modified integrated images. The most prominent one is security risk. The absence of security updates indicates that known vulnerabilities will persist permanently and can easily become the target of viruses and hacker attacks. Secondly, there are stability risks. Unofficial modifications may introduce unknown conflicts, causing the program to crash or data to be damaged.
For those users who still have to use the old version of the software, if they must use the integrated version, it is recommended to use it on machines that are not mission-critical, and to back up important data. From a long-term perspective, planning for hardware and system upgrades and then migrating to supported software versions is the fundamental way to ensure work efficiency and data security.
Do you, for some reason, still continue to use a certain classic software that has long been "outdated"? Feel free to share your specific experiences and reasons in the comment area. If you feel this article is helpful, please give it a like to show your support.
