Release 49

2000-09-22

 This Release's Editorial

Work is getting busy so I haven't had a lot of time to devote to WFC. This release is mainly bug fixes. I've been learning a lot about creating database driven web sites. The lessons learned so far are:

  1. ISAPI Extension DLLs are very cool
  2. ODBC to SQL stored procedures is very cool
  3. COM SUCKS!
  4. ASP SUCKS!
  5. .NET looks promising
How did I come to these conclusions? Well, I was given the task of creating a website that can handle medium-grade traffic (thousands of simultaneous users, each performing database queries and disk-intensive operations). So I started reading the propaganda, er, I mean, articles about web site creation. We knew we wanted to scale the web site to clusters (database, web server and search engine clusters) to handle the traffic. As more users hit the site, more boxes will be added to the clusters. Seems like a reasonable design. We came up with two approaches:
  1. C++ extension DLLs using ODBC to talk to SQL stored procedures and
  2. ASP pages using ADO to talk to SQL server.

I was on the team doing the extension DLLs and another team did ASP pages. In a head to head comparision, extension DLLs were the far better solution. To deploy the extension DLL, you need to put one file in the /inetpub/scripts directory. That is all. Now, what is all this business about "DLL Hell"? The ASP solution required creating a virtual directory and putting several ASP files in it. Where things got interesting was in server side charting. One of the requirements of the systems was security. This meant no Java, no ActiveX, no DHTML, nothing fancy at all. Just "flat" HTML and JPGs flowing to the clients. This allows us to work with all browsers. This also meant when the user wanted to see a pie chart representation of their data, we had to render the chart on the server and pass down a JPG image of it to the browser.

We first used Office Web Components (OWC) for charting but in order for it to work, we had to create an ASP page to generate the chart and create our own Visual Basic ActiveX control to read a binary file (not possible in "ASP Hell," you can only read text files, see Knowledge Base article Q193998).

The ASP team found and used an OpenGL charting tool from Dundas Software. This looked really sharp so I tried to use it from an ISAPI extension DLL. Bad move! The Dundas ActiveX requires an installation (because COM objects cannot exist without making entries in the registry) and has a nasty habit of locking up IIS 5.0 requiring a reboot of the server to fix (DLLHOST.EXE goes off into never never land). The guy stuck with getting the Dundas tool to a stable point spent the better part of a day figuring out that he must assign the return value of a function call to an unused variable in an ASP page (just calling the function without storing its result caused IIS to lockup). We are now trying to buy the source to Dundas' charting tool so we can rip out all of that COM crap and get out of "ASP Hell".

If anyone knows of source code to some OpenGL charting routines, I'd be very grateful to hear about it. We want to get back to having a single DLL contain the entire site so we can have a single file copy installation procedure. We can't afford to get stuck in "COM Hell" if we can avoid it. The main lesson learned from this project is "Don't use anything on a website that you can't debug."

Interestingly enough, Microsoft is trying phase out COM with their new .NET framework. I think they've finally come to the same conclusion I did about COM, it is too complex. COM does a fantastic job of giving VB scripts access to functionality but it is far too fragile to be used for any real work. COM has never allowed the granularity of reuse I've needed to get my job done. If the producer of a COM object doesn't expose a customization point that you need, you cannot use that object in your system. Never mind the fact that COM objects require a per-thread initialization that can really screw you (that's why you can't use COM objects in ISAPI extension DLLs unless you create your own worker thread pool, it is also the reason why you can have only 60 or so COM objects produced with MFC per NT4 process). If you have source code, you can create your own customization points to your heart's content.

 New

CNetworkUsers - Added a method named ExpirePassword() to expire a user's password. This makes it easy to force all users on a domain to change their password at the next logon. Thanks go to Udo Krummrey for suggesting this.

 Modified

CTape - I broke the interface. Please accept my humblest apologies. Read and Write have been renamed to BackupRead and BackupWrite. This is to preserve the interface with CFile and give you the ability to read and write raw data to the tape.

 Fixed

CString - Thanks to Larry Bredehoeft, the STL version of the TrimRight() and Right() methods now work without relying on exception handling.


Release 48 Notes

Sam Blackburn
wfc@pobox.com
Return to Sam's Home Page