Migrating a Web Server to IIS 5.0

Porting CGI Applications

IIS 5.0 supports the CGI 1.1 standard. Porting a CGI application to IIS 5.0 from a Windows-based Web server is fairly simple, and you do not need to make many changes for the application to run. The most frequent problems encountered by individuals porting a Windows-based CGI application to IIS 5.0 are installing the application in the correct directory and configuring security. You also need to make sure you have the necessary script interpreter installed, if the application consists of a script. These issues are covered in the “Configuring CGI Applications” topic in the IIS 5.0 online product documentation.

Porting a CGI application to IIS 5.0 from a UNIX-based Web server requires some work to bring it into conformance with Windows file and application conventions. For more information, see Special Considerations for UNIX Applications.

Another type of CGI application, WinCGI, isn’t as easy to port. WinCGI was developed as a simple way to get Visual Basic applications to work with the O’Reilly Web server. Visual Basic doesn’t normally use the standard input (stdin) and output (stdout) streams or environment variables as do CGI- and character-based applications. Therefore, WinCGI takes the query string arguments, server variables, and stdin data and places them in an .ini file. The application then reads the .ini file for input and writes to it for output. WinCGI isn’t supported on IIS 4.0 or IIS 5.0, and you cannot directly port applications based on WinCGI. You have three options for dealing with this type of application:

Rewrite it as a CGI that uses standard input and environment variables to transfer data.
Rewrite it as a script in an ASP page.
Write an ISAPI DLL to host WinCGI.

ASP is by far the best solution for anyone who wants to write IIS 5.0 applications in Visual Basic. ASP is very fast. In addition, it’s designed to work with VBScript, and contains built-in objects that make application development easy—you can write a script in Notepad in seconds without having to build an .exe or a .dll file. Finally, ASP is robust with COM, is fully supported, and handles non-thread-safe components (although it’s faster with thread-safe components).

For more information, see Configuring a Script Interpreter.