Making Software Work Together
I recently hosed my NT desktop system. This system runs NT Server 4, Service Pack 3, Internet Information Server (IIS) 4, Office 97, Internet Explorer 4 and many more applications. The system normally runs for many months with very few problems and is a testament to the stability of NT Server. The hardware is a Toshiba Tecra 730 CDT.
Well, all good things do not last. One day recently I was working on the system and one of my friends called. He asked why I did not have the sound software installed to let me know when messages came in. The sound drivers come from Toshiba and are installed as part of their utilities. Well, I figured I could solve this quickly by just installing the utilities. It was late Sunday night and I was tired. …
So, start the Setup program and off we go. I should have known better. I am now making it a policy not to install software on a system after 10:00 p.m., unless the entire system is being rebuilt from scratch or there is an emergency. But, I digress.
The Setup program ran as expected, and then asked me to reboot. Without thinking, I selected Yes and went to work on something else. That was it. I was never able to log into that system again. The logon would start, but never complete. Explorer would die as the logon process proceeded, and the Explorer interface would never appear.
What did I do to resolve the problem? I connected to the system from another system and copied the data files off. Then, it’s time to FDISK and -- well, you get the picture.
Then a few weeks later, I went to the Midwest to teach a Visual InterDev 6 class. The software for the class had been installed by the guys that work for the client. There was a server running NT Server 4, IIS, SQL Server and other software. The client had also installed Office 97 on the same system. Not a big deal, unless you install things in the wrong order. The client had installed NT, then SP3, the NT Option Pack, then Office 97. This resulted in a server that would not work in certain circumstances and would exhibit strange behaviors in others.
We fixed the server by uninstalling the NT Option Pack, reinstalling NT Service Pack 3, then NT Option Pack, then the server software for Visual Studio 6.Then the server performed flawlessly with no problems.
Lots of folks have run into software problems on various systems. Is this Microsoft Corp.’s fault or even that of any other company? No. The problem comes from having lots of software from different sources on the same system. I remember way back in the 1980s when I had created a system that ran on IBM Corp.’s VM/SP system. One Sunday I traveled about a thousand miles to our company headquarters. I had just walked into the office when I was told about an upgrade to the mainframe that had occurred over the weekend. I panicked. The support staff said, "Don’t worry; it will not affect your application." Ha! That’s when I got a panic call from my plant saying the software would not run. I had to jump through hoops to fix it.
The problems with many different software systems are legion. The problems are not necessarily the fault of any one vendor. The COM specification is designed to keep many of these problems from happening. Software authors do not adhere to the standard, and thus the problems occur. Microsoft and others are working to solve these problems in many different ways, such as developing COM+. For one, Office 2000 will fix many of these problems when it is released. It will automatically detect problems when it loads and reinstall the support software to fix any problems that occurred with its configuration -- all without user intervention.
Solutions such as Office 2000 and others are the answer to many of the problems we face today. Building the intelligence into the software packages will go a long way to ensure that packages do not interfere with each other. --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.