Visual Basic Developer[ap]s Guide to ASP and IIS

	Chapter 1 - Visual Basic and the Web
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Chapter 1: Visual Basic and the Web

	Overview

	Visual Basic was an instant hit in the Windows programming community but so far it hasn't been a major force in the Web programming world, except peripherally, through VBScript. (Microsoft selected Visual Basic's young "challenged" cousin, VBScript, as the default programming language for their Active Server Pages, or ASP, technology.) There are several reasons why VB hasn't been the language of choice for Web programming.

	First, Visual Basic runs on only one platform, Windows. Until Microsoft's Web server, called Internet Information Server (IIS), became commonplace (about three years ago, with the introduction of version 3), VB couldn't talk directly to the Web server. This made it tough to use VB for the Web. You could do it, though, and some people did.

	Second, VB has a large runtime dynamic-link library (DLL) that gets loaded whenever you run a VB application, even if the compiled application is only a few kilobytes of code. The large runtime made VB programs running on the Web painfully slow. Each time a client browser requested a Web page, the Web server had to dutifully load the runtime DLL, load the application, process the request, and then unload the application and the runtime DLL. Because the Web works on a get-in, get-the-data, get-out-quickly schedule, it's overkill to load a 1MB-plus application-support DLL simply to provide a little marked-up HTML text. Furthermore, because your application "died" after each request, storing data values between requests was difficult—which meant that the approach was primarily useful for formatting simple requests and database reports, not full applications.

	In an attempt to alleviate these problems, Microsoft provided an application programming interface (API) called Internet Server API (ISAPI), through which programs could communicate with the Web server. However, the company neglected to provide VB with the means to access the API. Microsoft also "solved" the problem of large support DLLs (after all, Visual C++ has one, too) by letting you load DLLs directly into the Web server's address space. That way, they stay loaded all the time, which dramatically speeds up response time. ISAPI was an instant hit, but you couldn't take advantage of it until Visual Basic 5 provided the capability to create compiled DLLs. Unfortunately, this capability also dramatically decreased the stability of the Web server, because if one of the in-process DLLs crashed, the Web server often went down with it.

	Meanwhile, several methods of connecting VB applications to the Web server appeared. A freeware DLL called Object Linking and Embedding Internet Server Application Programming Interface (OLEISAPI and later OLEISAPI2) provided connectivity between VB applications and the Web server. Other, relatively full-featured solutions not only provided connectivity, but also loaded a configurable number of instances of your application, provided load balancing between them, and enabled you to connect one instance to a single user so that programs could keep user-specific data between requests on the server. These solutions also kept program instances alive between client calls to the Web server, so you could store data easily in program variables.

	In addition, you could (and still can) program directly to the underlying protocols. Carl Franklin (of Carl and Gary's Visual Basic Home Page) wrote an excellent book called Visual Basic 4.0 Internet Programming, in which he discusses Winsock programming, the use of various Internet protocols, and other low-level programming topics for the Internet. All that information is still valid, and if you want to get "under the hood," Carl's book (since updated for VB 6) can do more for you than this one.

	Luckily, with VB 6, Microsoft has finally provided Visual Basic with a direct connection to the Web. The method they provide works via Component Object Model (COM) automation through one or more ASP pages. You build a DLL that exposes a WebClass object. The client calls an ASP page that loads a copy of your DLL. From then on, you use the WebClass methods, properties, and events to deliver content from template files and/or created on-the-fly to the client browser.

	If you don't understand all of this right now, don't worry—by the end of this book you will. The important point to remember is that WebClasses aren't a brand new technology and they aren't difficult to understand. They don't do anything you can't do with Visual Basic 5 and an ASP page or two—they just do it more easily.