Migrating a Web Server to IIS 5.0

Converting CGI to ISAPI

ISAPI extensions are Web applications implemented as DLL files. Converting a CGI application into an ISAPI extension will improve its performance.

ISAPI extensions run faster than any other type of application on IIS 5.0. ISAPI extensions run in the same memory space as the Web server, or in a pooled application process, unless a separate process is called. IIS 5.0 typically loads an ISAPI DLL the first time a request that calls the DLL is received. The DLL then remains in memory, ready to service other requests until the Web server is stopped or until the DLL is manually or programmatically unloaded.

Rather than using environment variables and standard input/output (I/O), as CGI does, ISAPI extension DLLs communicate through a data structure called the Extension Control Block (ECB). A small set of functions allow the DLL to communicate with the Web server. Because function pointers are used to communicate with the server, applications written in languages that support function pointers, such as C, C++, and Perl, are good candidates for conversion to ISAPI. CGI applications written in Visual Basic should be rewritten as ASP applications.

Perl scripts run most efficiently under ISAPI. PerlIS.dll, also called Perl for ISAPI, is an ISAPI extension that runs Perl scripts on the Windows operating system. Using the Perl for Win32 Perl.exe rather than PerlIS.dll to run your Perl scripts requires that the server create a new process for each request. For information about obtaining and installing PerlIS.dll, see Configuring a Script Interpreter.

Creating ISAPI DLLs requires a thorough understanding of the Win32 programming environment, including thread management. For some useful information sources on Win32 programming, see Additional Resources at the end of this section.

Note An ISAPI DLL can be deployed by the developer or system administrator to run either within the IIS 5.0 process, in a pooled process with other DLLs, or in its own process. Developers frequently configure their applications to run out of process until they are fully tested because, should they malfunction, they won’t affect other applications running on the computer. Once applications are fully tested, they are then configured to run in a pooled process for faster execution. Or if an application is prone to violation errors and failures, it can continue to run out of process on the production Web server.