Your Letters

tele/scope
October 29, 1997

Norvin Leach
MSDN Online News Editor

It's the end of October in Seattle. The trees are almost bare. It's rainy, it's cold, and it's bleak. It's time to find shelter. Time to spend the long, lightless days contemplating mortality and catching up on letters to MSDN.

ActiveX

Lots of responses to the ActiveX column, mostly thankful for an explanation of the marketing terms. A few questions came up, though:

Most of the demos at the PDC used scriptlets and DHTML. This looks like Microsoft is, indeed, de-emphasizing ActiveX in favor of scripting. In fact, there are few, if any ActiveX controls on your Web site. And what about Java applets? Give us some guidelines on what we should use, and where we should use it.

To tell you the truth, this one stumped me, so I asked Christine Chang, a product manager in our Platform Group. Here's her answer:

Web developers should use the right tool for the job, based on what they're trying to accomplish.

• Scriptlets are the easiest way to create and present reusable interactive content. With scriptlets, HTML and script authors can leverage existing expertise to create these components, without having to learn new languages such as C or Java. Given that scriptlets are HTML- and script-based, they download and run very quickly compared to controls and applets. However, unlike applets, scriptlets are not supported across browsers. They will be delivered in all versions of Internet Explorer 4.0 including Windows 95, Windows NT, Windows 3.1, Macintosh, and Unix.
  
  
• ActiveX controls provide more powerful language functionality, compared to both scriptlets and applets. They also provide easier access to system services such as the registry or print queues, compared to applets. Scriptlets do not have access to system services.
  
  
• Java applets provide more language functionality than HTML and script, although they can't access system services as easily as controls. With extensive testing and debugging, it may be possible to develop an applet that runs across multiple browsers and platforms. However, it's difficult to port significant functionality across multiple platforms. In addition, applet performance on Windows 3.1 and older Macintosh systems is often very slow. As a result, applet use is impractical on these platforms.

What happened to the ActiveX Gallery?

It's gone. That was introduced last year specifically as a marketing tool to get people familiar with the concept of ActiveX controls. It did its job, so we took it down and moved the resources elsewhere. You can find examples of ActiveX controls at the Browserwatch Web site (http://browserwatch.internet.com/activex/activex-big.html), or C/Net's How-To Web site (http://www.activex.com/). Or, even better, you can search through our ISV partners with the new MSDN ISV Directory (http://198.206.247.245/MSDN_ISV/html/Direct.asp).

Bedlam

I asked for some help-desk horror stories, and the best/worst story came from Geoffrey Feldman. It's hardware-related, but nonetheless good enough to relate:

22 years ago I was Technical Director for a little place called "The Computer Store" in Burlington, Mass. We sold Altairs and yes, Microsoft products with them. Altairs at the time came in kit form. Not motherboards and chassis but chips and boards with no solder yet. The Altair had a huge bundle of wires that went from the front panel to the motherboard.

A customer came in after attempting to build one of these things. As was often the case, he had not been successful. When I opened the case, a horrible odor of bad breath permeated the room. As I peered down into the wiring, I noticed that it was tied together very neatly (this was recommended) but he had tied it together with dental floss. Used dental floss. A quick call to the guy got his permission to spray the computer with Lysol before the service operation commenced.

On a more serious note, I'll end with an observation by one writer, who suggested that I missed the most important lesson of the Bedlam incident:

Scalable systems require administrative controls that are not necessary on systems that will remain small. The point is that by the time the mess got going, there was no way to stop it. The recent trend toward monolithic, opaque software makes this problem even worse.

I suggest that developers be required to read the comp.risks list before writing the first line of code each day. It's too easy to get buried in the task of writing and shipping code and lose perspective on the way that the system you are creating will be (mis)used.

Send me more mail.