Win32 Support for Server-Based Programming

In the computer world, an interface is a set of operating system functions that determine how your program performs its tasks . An application programming interface is analogous to a user interface. Think about how you use a word processor. When you are entering text into the computer, the UI controls how you direct the word processing program to do what you want, and the program provides feedback through the UI. For instance, the word processing program I use (Microsoft Word) initially presents me with a blank document. A menu and a toolbar appear at the top of the window, allowing me to quickly access frequently used items. (See Figure 1-5.) Just below the toolbar is a ruler control, which might be the most familiar part of the interface for those of us old enough to remember typing on a real typewriter.

Figure 1-5 The Word UI.

The program gives me feedback as I use it: I type and text appears on the screen. More subtle examples of feedback from the user interface exist as well. For example, if I were to misspell something or use a proper name like "Reilly," the program would display a squiggly red line under the word to communicate its recognition of a possible misspelling. Microsoft WordPad, the basic word processing program that ships with Microsoft Windows 2000, lacks many of these feedback features. However, its UI (shown in Figure 1-6) is very similar to that of Microsoft Word.

Figure 1-6 The WordPad UI.

In the same way that a UI allows users to send and receive information, an API allows programmers to call a function and receive status information in a structured way. For instance, the API for the standard C run-time library provides a set of functions (such as fopen and fread ) that allow the programmer to work with files. In the case of fopen , the function returns NULL if the file cannot be opened. The programmer can check the global variable errno when fopen returns NULL to receive feedback on why the function failed.

You've noticed that the user interfaces of similar programs, such as word processing programs like Word and WordPad, are similar. Although differences exist, similarities make switching from one program to another easier. Many APIs are also similar in external structure. Their similarity makes them convenient to use. For instance, many APIs have three phases: first you allocate and open resources; next you use the resources; and finally you close and free resources previously opened. Thus it is reasonable to generalize from one API to the next . If you have used the C run-time library functions, you should have little difficulty using a named pipe (even though a named pipe is internally very different from a file). In addition, many Windows APIs use the same kernel synchronization objects. (Kernel synchronization objects will be discussed in Chapter 2.) These objects are used in a similar manner with each API: you create or open the object, use it, and then you close the object's handle.

Many APIs support server development within Windows 2000. Some of them will be briefly mentioned here and some will receive additional coverage in later chapters. Not all the APIs we discuss will be similar. However, some of these APIs do resemble other APIs, and that can make future learning easier.

The Console API

You probably know that you can run many MS-DOS programs in Windows 2000. You might also know that you can create 32-bit console applications. But do you know which of the following API functions cannot be called by a 32-bit console application?

LoadLibrary
MessageBox
RegQueryValue

OK, this is a trick question. You can call all three functions. And that is the point of this discussion: the tasks performed by a Windows 2000 service can be accomplished by a console application. One of the best ways to start creating a service is to create a console application that has the required functionality before converting the application to a service.

You can use the Microsoft Visual C++ new application wizard to create a basic framework for console applications. Within the framework created by the wizard, you can use the C run-time library functions to print messages to the console, which allows you to display messages similar to the way MS-DOS text-based programs do.

The Service API

Given that a console application can perform the tasks of a service, why bother converting a console program to a service? First and foremost, a server application often needs to run on a server computer that might be locked away somewhere in a computer room. Probably no one will be present at the console of the machine to run the server application if the machine is restarted. In the "good old days" of MSDOS systems, you could work around this (and I actually did) by making sure that the Autoexec.bat file set up any necessary conditions (such as network connections) and then started the server application. Unfortunately, Windows 2000 might not be able to set up all of these necessary conditions. Windows 2000 provides an alternative method of performing such a task; this method is a service. Windows 2000 makes it easy to automatically restart a service after a computer server restarts.

You create a service using the service API. Two service API functionsthe service main function and the control handler functionallow a program to register as a service with the Service Control Manager (SCM). Further, the program can run under the authority of the system account or another user's account. (Programs that run under the authority of another account have the access rights of that account.)

The Impersonation API

The service API allows a service to work under the authority of the system account or some other user account. However, imagine you were creating a service that would read and write files on the server. If the service was running under the system account's authority or a user account with administrative authority, it could clearly access all the files on the server. This situation might be appropriate in some cases, but what if you wanted to give users different authorities?

One option would be to create a security system for your application that would allow you to specify the rights for each user based on the directory where the files are located. This would not be a trivial undertaking; it would require administrators of the system to methodically set up security for each of the users who will act as clients connected to the server. Fortunately, we can avoid this kind of redundant work because there is a better way to give users authoritiesimpersonation.

Several APIs support impersonation. Much like guests at a costume party, the services can put on different user "masks" when required and operate on resources as if they were being run by other users. This ability to impersonate another user and then allow the operating system to do its normal rights checking could be duplicated programmatically if programmers tested the rights of the user on the client machine for each operation. Impersonation is much better because the check is done by the operating system at the time of each request.

The Event Logging API

Event logging allows programsnot merely serversto log events as special system supported files. In fact, most entries in the event log of a normal Microsoft Windows NT system will be service- related messages. The event logging API allows for more than just message logging. The messages can be retrieved from the local machine or, with proper authority, from a remote machine. In addition, you can save messages in different languages. This is clearly a better method of handling error messages than the humble printf statement.

RAS, MAPI, and TAPI

Remote Access Service (RAS) is software that allows remote clients to access a network server by means of a modem. RAS allows you to connect to a remote computer and its network as if your computer were on the remote computer's LAN.

TAPI allows you to use a computer to interact with the telephone. Using TAPI, you can dial or answer the phone, as well as retrieve caller ID information about incoming calls. Advanced support for call-center operations is also available. Of course, you could try to manually interact with the serial ports, but TAPI provides a more integrated solution.

MAPI supports applications that need to send and receive e-mail. Why might a server need to send or receive e-mail? Well, for instance, imagine a hospital financial system that tracked billing exceptions. A good implementation of this system might mail a report of outstanding exceptions to the responsible parties each evening.

NOTE

---

Some competing e-mail options might be worth consideration today: Post Office Protocol (POP) and Simple Network Mail Protocol (SNMP) are both noteworthy. We will not be covering these options.

Database Connectivity

Eventually, your server will need to connect to a database. The differences in performance between the various options and the stated direction of Microsoft for database access from Win32 platforms means you have a lot of decisions to make. We'll examine two popular database connectivity options: Open Database Connectivity (ODBC) and Active Data Objects (ADO).

ODBC is a long established option for database access. Most databases are accessible through one or more ODBC drivers. In addition, many tools exist for manipulating ODBC-compliant databases, including Microsoft Access and Seagate Crystal Reports. Visual C++ also has support within MFC for ODBC compliant databases.

ADO provides a more object-oriented method of data access. The Connection and Recordset objects, among others, allow for connection to databases and the retrieval of records. This model is frequently used with some of the technologies related to Microsoft Visual Basic such as VBScript, but Visual C++ programmers have other reasonable alternatives.

Active Server Pages

Strictly speaking, Active Server Pages (ASP) is not an API, but it does provide support for the creation of server applications. ASP is supported by IIS on Windows 2000; on Windows 98, it is supported by means of a similar system known as Personal Web Server. Whereas ASP is primarily for use on Windows 2000, it is also available from third-party vendors for UNIX.

ASP is server-side script that gets executed on the server with the intent of delivering HTML content to the browser. The script is often VBScript, though JScript (Microsoft's version of JavaScript) is supported as well. VBScript is a simplified version of Visual Basic that supports much of the same functionality as Visual Basic, with some important exceptions. The chief difference is that you don't need to type variables every variable is a variant. In addition to script running directly, it can use compiled components for augmentation by creating objects based on ActiveX controls.

The Internet Server API

The Internet Server API (ISAPI) is Microsoft's solution for creating high-performance Web applications. In the UNIX world, Internet server applications are almost invariably Common Gateway Interface (CGI) applications. Grady Booch, father of the Unified Modeling Language and author of many books on object-oriented analysis and design, says CGI is "The Duct Tape of Web development" (Software Development Conference, May, 1999). CGI is a standard for interfacing a Web browser with an external application. When the user enters a URL that points to a CGI script, the browser executes the script. The information from the browser, including the URL typed into the address bar (and information entered in any HTML form) is passed to the CGI program. The CGI program then generates HTML output and sends it to the standard output using printf and similar functions.

This approach is problematic for several reasons. The most significant is that spawning a new process each time a user request comes in is fairly expensive, limiting the scalability of the server program. In addition, no explicit support exists for programs to parse the incoming information.

ISAPI is the solution for Web developers who work on Windows 2000 using IIS. ISAPI allows the creation of DLLs that export specific functions and can be called by IIS when required. The ISAPI DLL is loaded into the memory of IIS and, once used, remains loaded until IIS is unloaded.

ISAPI extensions

ISAPI supports two distinct interfaces that allow creation of very different applications. The first is an ISAPI extension. ISAPI extensions are DLLs that are called in the same way as CGI programs: as part of a URL or as a default action for a particular site. For example, imagine an ISAPI extension named GETINFO.DLL that exposes a single function named GETNIC . If the DLL is stored on a machine named PRO, the following URL calls the ISAPI extension, loading the DLL into the IIS memory space if required:

http://pro/getinfo.dll?getnic

This process is a huge improvement over CGI, and it can often offer impressive improvement over alternatives such as ASP.

ISAPI filters

ISAPI filters are similar to ISAPI extensions in the way they are implemented, but their functionality differs significantly. While ISAPI extensions duplicate functionality that could also be provided by CGI or ASP, ISAPI filters provide functionality that cannot be easily duplicated other ways.

Like ISAPI extensions, ISAPI filters are DLLs, but unlike extensions they are never called directly. Instead, every call to the Web server where the filter is installed passes through the filter, presuming that the filter has told IIS that it wants receive the particular notification.

What are ISAPI filters good for that ISAPI extensions, ASP, or CGI are not? One primary use for filters is to create custom user authentication. Since every session generates one notification that allows the ISAPI filter to authenticate the user, custom operations can be performed. Other common uses include the compression and encryption of content.

Communication APIs

Virtually no server is an island. Thus, in addition to RAS, TAPI, and MAPI, which are often used to communicate with remote clients, other protocols exist that allow the server to communicate with local clients. (Using RAS to establish the network connection, these APIs can be used to communicate with more remote clients as well.) Note that while we will be developing servers, it is not uncommon for a "server" to be in the role of "client" with respect to other systems. An example of this situation is a communication server in a healthcare organization that needs to communicate with a central hospital system. From the perspective of the end users of the communication server, the server is a server. However, to the central hospital system, the communication server is in fact a client. We will be covering communication APIs in Chapter 12, but they are not the central thrust of this book. Other books specifically dealing with the client/server interaction offer more complete coverage.

TCP/IP

The Internet has made TCP/IP almost a household name. When we use TCP/IP these days we are usually using some "well known" protocol such as HTTP, FTP, or even Telnet, but our own servers will often need to communicate to clients using our own custom server.

TCP/IP is normally accessed using sockets, a common UNIX API suite that allows both clients and servers to communicate with each other. Windows 2000 supports Windows Sockets (commonly referred to as Winsock), a modified version of the standard sockets API. Winsock is a superset of the standard UNIX sockets, which emphasizes support for the cooperative multitasking model used by Windows 3.x. We will primarily cover those parts of Winsock that are appropriate for serious Windows 2000 server development.

Named pipes

Named pipes is an alternative to TCP/IP. In some cases named pipes offers significant advantages, while in others it can create an application that is slower than it otherwise would be if it used TCP/IP. Using named pipes is similar to working with files, which is not surprising, since named pipes is actually implemented as a file system. If you search the registry on a Windows 2000 machine for NPFS (Named Pipes File System), you will see it listed along with the other file systems.

Named pipes is an authenticated protocol, which presents both some challenges and some opportunities. Regarding the challenges, services accepting named pipe connections must take special care and allow the service to run under the local system account. As for opportunities, named pipes allows for convenient impersonation, using the ImpersonateNamedPipeClient function. Named pipes can be about as fast as TCP/IP on a local area network, although my experience is that establishing the connection can take longer than TCP/IP. Over a wide area network, the speed difference becomes more noticeable and TCP/IP generally comes out on top.

NOTE

---

Named pipes has one unusual feature. If a client and a server are located on the same machine, a local pipe is used. This arrangement offers outstanding performance and would always be my choice when the client and server can be or might be located on the same machine.

When choosing communications protocols it is important to consider whether your testing requires that you use a Windows 95 or 98 machine as a "server." If it does, TCP/IP is the only choice between these two protocols. Only Windows NT or Windows 2000 can act as a server for named pipes.