The weekend was typical for the Lab Guys. We ignored the bright, sunny skies and slinked into the artificially lit Lab to putter around with some non-mission-critical products. Tinkering in the Lab on the weekend is how the Lab Guys usually relax, but this weekend was different.
A couple of products that just didn't work quite right in the Windows NT environment were plaguing us, so we decided to dirty our hands and figure out why. We're sure you've seen such products before--vendors develop them for Windows 3.x or Windows 95, but only half-heartedly port them to NT. Our experience with such products over the weekend resulted in a list of demands for software vendors.
Demand 1: Provide an Uninstall Component
We are not amused by the lack of an uninstall component in a software product. You may think your product is so wonderful that users will never remove it from their computer, but you are wrong.
We spent Saturday trying to get a serial port-sharing package to work on a server. (We won't tell you the package name because this column is not an objective product review.) The software installed fine, the port-sharing service started, but we couldn't configure the ports we wanted to share (and yes, we read the documentation). We even searched the Registry for port settings.
After hours of fruitless experimentation, we decided to remove the product. That's when we discovered that this software did not have an uninstall component--we had to manually delete the directories, files, services, and related Registry entries. Later, we learned that an .ini file could have solved our port-sharing problem (we'll explain how we made this discovery later). This discovery takes us to our second demand.
Demand 2: Get Rid of .ini Files
We hate .ini files! They are physical evidence of the shortcuts companies take to get their products to the NT market. Commercial-grade NT software packages shouldn't use .ini files; they should use the Registry to store system configuration information.
On Sunday, we decided to try out the beta NT driver for the Connectix QuickCam color camera. You can use this small desktop camera as a source for video conferencing via Cornell/White Pine's CUSeeMe, Microsoft's NetMeeting, or similar conferencing packages. With all the high-end video products coming to the NT market, we assumed the low-end consumer products would be ready for prime time.
The QuickCam driver installed without problems. However, the installation procedure created a program group with two program items that didn't exist. The documentation warned that these program groups would install, but why would a vendor want its software to install references to programs that don't exist? The answer is easy: The vendor is using its Win95 installer procedure and wants to modify it as little as possible. But beta code is beta code, so we just deleted the obsolete icons and moved on.
The QuickCam plugs into a parallel port. We already had a printer installed on the first parallel port, so we added a second parallel port for the camera. After installing the drivers and plugging the camera into our new port, we ran into a problem: When we started up CUSeeMe, the printer started spitting out reams of garbage. This dilemma was a good indication that the driver thought the camera was on LPT1 and not LPT2.
No problem, we thought; we'll just make a small configuration change. We opened the video camera Properties dialog box in our video conferencing software, but we found no port settings. We went to the Control Panel, but we found no QuickCam applets. We even swapped the printer and the camera, just to make sure our assumption about the driver's confusion was correct. It was; when we switched the ports, the camera worked.
We could have given up at this point, but hey, we were spending the weekend in the Lab, and this project was supposed to be fun. Again, with no luck, we searched the Registry for configuration variables. We started to pore over the product's technical notes, and we ran into a reference to (gulp) an .ini file.
We soon discovered that the QuickCam drivers maintain the setting information in an .ini file in the NT root directory. We opened this file with a text editor, modified the port setting, and voilà! The camera worked on LPT2. Coincidentally, when we were in the root directory looking at the QuickCam .ini file, we ran into the .ini file for the serial port-sharing product. A glance inside the serial port-sharing .ini file showed us how we could have configured the software to cure Saturday's product uninstall dilemma.
You'd think that at this point we'd be reasonably happy. After all, we got our camera to work on the parallel port we wanted. Unfortunately, we had one tiny problem--whenever we ran the video conferencing software (CUSeeMe or NetMeeting), the CPU in our 200MHz Pentium shot to 100 percent utilization and remained there.
This situation was strange because the same software and the equivalent drivers run under Win95 without taking over the entire machine. We identified why the software was having this performance problem, which leads to our final demand.
Demand 3: Don't Hog the CPU
Run the NT Performance Monitor on your products. If you are a software developer and you don't know how to run Performance Monitor, learn it! Don't release software that takes over the whole machine. NT is a multitasking operating system that Microsoft designed to run multiple applications.
Monday Looks Pretty Good
By the end of the weekend, we had experienced our fill of non-mission-critical products. We were eager to go the Lab on Monday and start working again on large, complicated, enterprise-oriented software. After all, enterprise software includes an uninstall component, doesn't use .ini files, and always arrives tuned for NT.