- Introduction
- The "Soft Lock"
- Creating a Virtual Development Environment
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The "Soft Lock"
Thankfully, Windows NT has evolved. The arrival of Windows 2000 and especially Windows XP allows the introduction of a new lockdown system: the "soft lock." Both new operating systems include improved versions of NTFS. In a pure Windows 2000/XP environment, the power user and even the administrator can do a lot less damage than under Windows NT.
Four new Windows features support soft locks:
- Windows System File Protection
- Windows Installer service
- Windows XP DLL Loader
- Run As command
When used appropriately, these four features help contribute to a full-fledged local development support solution, even if you've given installation rights to a user.
Windows System File Protection
First introduced with Windows 2000, Windows System File Protection (SFP) was designed to protect critical system files. This watchdog service constantly monitors Windows' operational folders. Every time a file is replaced or destroyed within one of these folders by anything other than the operating system, SFP automatically replaces it with the "authorized" version of the file.
SFP stores spare copies of the correct versions of critical system files in a special folder named DllCache. It's easy to see SFP in action:
Make sure that you have administrative privileges on a Windows 2000 or XP system.
Move to \Windows\System32 (on a Windows 2000 system, this folder is \WINNT\System32).
Find and delete the Calculator file (CALC.EXE).
Empty the Recycle Bin.
Watch the System32 folder. CALC.EXE should reappear within seconds.
SFP constantly replaces critical operating system files. This feature is on by default on all Windows 2000 and Windows XP systems.
The Windows Installer Service
The second feature that supports the soft lock is the Windows Installer service. This service is designed to fully support the software lifecycle on Windows systems (see Figure 1). One of its greatest advantages is application self-healing. Every application that's installed through the Windows Installer service is automatically self-healing—even applications that weren't designed for it.
During installation, the Windows Installer service copies every detail of an installation into a coherence database located on the workstation. When an application is launched, the Windows Installer service double-checks application components, registry keys, configuration parameters, and more against this database. If anything is amiss, it automatically launches a repair cycle. Once the application is repaired, it continues its normal launch cycle and opens. The only thing the user sees is the Windows Installer service dialog box—for a few seconds, just before the application starts.
)
Figure 1 The Windows Installer service supports the software lifecycle.
In this way, IT can ensure that every application or commercial software product they deploy will always work, no matter what happens. Thus, the developer can now be given installation rights, because IT knows that their own applications will always repair themselves, even if other non-corporate applications have been installed on the system.
Only software displaying the Windows 2000 or Windows XP logo uses the Windows Installer service by default. Obviously, this doesn't include every software application on the market. But if IT wants to partake of this service's features, they can repackage an application to integrate its installation with this service, transforming it into a Windows Installer installation format. Several repackaging tools support Windows Installer integration, of which the following are a few:
- Wise for Windows Installer and Wise Package Studio
- Lanovation Prism Pack
- Veritas' WinInstall LE (on the Windows Setup CD) and WinInstall 2000
- InstallShield Admin Studio
In addition, a full self-healing support infrastructure requires the constant availability of installation source files on the network.
There are a lot of justifications for the integration of a corporate network's applications to this service for any organization moving to Windows 2000 or XP. In fact, this should be an integral part of any such migration project.
The Windows XP DLL Loader
The third soft lock support feature aims to remove the obligation to integrate applications with the Windows registry. The new DLL Loader can now make use of external files to read the parameters required to execute an application.
In preceding versions of Windows (since 95), every software product needed to write information in the system registry to be able to function properly. One consequence of this inscription is the association created between an application's data files and the application itself. For example, every DOC file is associated to Microsoft Word, every XLS to Excel, and so on.
Windows XP introduces the concept of the manifest, a digitally signed external file that includes all of an application's parameters. This looks a lot like the INI files we had with the original versions of Windows. The manifest is much like an INI file, but its integrity is ensured through its digital signature. If for some reason developers don't want to create or use a manifest, they can create public (digitally signed) or private configuration files, or even just an application-specific configuration file.
When an application is launched, the DLL Loader will first check to see if there is a manifest with the application. If not, it then checks for configuration files. If none of these exist, DLL Loader assumes that it's an older Windows application and returns to the registry to read the information required to prepare the application's operating environment.
)
Figure 2 Windows XP's DLL Loader can launch applications without
having to read the registry.
One of the great advantages of this application loading method is that developers no longer require access to the registry to test their code because the installation of an application is now limited to an XCOPY of a set of files. IT can thus lock down the registry without affecting developers.
Run As
Finally, Windows provides its own security context for the operation of applications. This is the Run As feature, which allows developers to test their applications without having to close their coding session in Windows. Thus, the developer can be logged on with a development account that has development privileges and test code using Run As, using an account with normal user privileges (see Figure 3). The Run As command only affects the security context of the application that's launched with the command—nothing else. Run As is clearly a tool that can increase the productivity of developers.
)
Figure 3 Run As lets you test applications using normal user access
rights.
Using the "Soft Lock"
All of these features lead to one thing—improved development support while maintaining IT service levels:
System File Protection ensures that the operating system is always stable.
Windows Installer service ensures that deployed software always works.
The DLL Loader ensures that the registry is properly locked.
Run As increases developer productivity.
Putting these solutions into place is not without cost. But the return on investment is quickly evident to all. Anyone putting a Windows 2000 or XP environment into place should already be making use of these features.