Acting on Updates on DLLs
In the last column I wrote about how Microsoft Corp. was addressing the issue of updating software with the new update features in Windows 98. Microsoft is not alone in addressing this issue: Symantec Corp. (Cupertino, Calif.,
www.symantec.com) does the same thing with its latest software. I use Symantec’s Act 4.0 for contact management, and it includes a feature know as "LiveUpdate" that can connect your system to the Symantec Web site or a dial-up site and provide updates to Symantec’s software. The LiveUpdate feature is installed into Control Panel and is executed from there.
You can use any Internet connection such as a LAN or modem connection to connect to the Symantec Web site. You can select the method of connection and the dial-up connection to use. The dial-up option uses the dial-up networking feature of Windows 95/98 and Windows NT 4.0. You can also dial directly into Symantec using the modem connection, which also uses dial-up networking.
Automatically updating software is a great idea, but if you are not careful, it can ruin your day as a system administrator. If you are careful, it can mean many days off and a system that not only meets it business goals but also manages to keep running on a continuous basis.
A problem develops because of various DLLs that every Windows system uses. A DLL is a software library that is loaded into a system’s memory when an application needs to use a function or other feature of the DLL.
When a program needs to use a function in a DLL, it can refer to that function by its name or by its position in the DLL. This is like trying to contact people you know. If you know their phone number, you can call them by using it. If they move in the same city, they can probably keep the same phone number. Say you call your friends a week after they move. No big deal: You still get your friends at the old number. If they move to another state and you call, you will probably get a message stating that the number has been changed to a new number.
However, if you try to find them using their address, you may have a surprise. If they move two blocks away, the new people living in your friends’ house probably do not know where your friends moved to. That means you are out of luck and have to try to find your friends using some other method, such as their phone number.
DLLs work in the same way. If you use a function in a DLL and call it by its name, you can find that function even if it moves around in the DLL. If you call a function by its position in the DLL, and the function moves in a new version of the DLL, your application will fail.
Another potential problem in a DLL occurs with the design of each function. Each function’s definition contains an interface. The interface is simply the design of the function’s inputs and outputs. This includes the parameters that are passed to the function and the return value the function passes to the calling program.
If you create a DLL and your program is the only one that uses it, then you can change it at will. You don’t have to worry about the DLL’s impact on other programs or what happens when another program uses the DLL. This is not the way most software today works. Windows 95, Windows 98 and Windows NT provide most of their features through many different DLLs. The veritable Windows API is provided thorough a number of different DLLs that both Windows and other applications can use.
If all developers follow Microsoft’s advice on DLL construction, then there will never be a DLL compatibility issue. However, all developers are human and things happen. The fear that I have is that a simple update to Act 4.0 on my system will drop in an older or newer version of some DLL that is used by many other applications. Sound far-fetched? Don’t bet on it. How many of us have had a clean system go belly-up after we have loaded new software? DLLs installed by application programs are one of the prime culprits when this problem occurs. Microsoft and others are working to solve these problems. As you take advantage of these new features, make sure that your systems are backed up and the various configurations can be duplicated. -- Ken Spencer has written several books for Microsoft Press and works for training organization 32X Corp. (Greensboro, N.C.). Contact him at [email protected] or via the Web at www.32nt.com.