Local Procedure Call Facility

Applications and environment subsystems have a client-server relationship. That is, the client (an application) makes calls to the environment server (a subsystem) to satisfy a request for some type of system services. To allow for a client-server relationship between applications and environment subsystems, Windows NT provides a communication mechanism between them. The Executive implements a message-passing facility called a Local Procedure Call (LPC) facility. It works very much like the Remote Procedure Call (RPC) facility used for networked processing (described in Chapter 1, "Windows NT Networking Architecture," in the Networking Guide). However, the LPC facility is optimized for two processes running on the same computer.

Applications communicate with environment subsystems by passing messages via the LPC facility. The message-passing process is hidden from the client applications by function stubs (nonexecutable placeholders used by calls from the server environment) provided in the form of special dynamic-link libraries (DLLs), as illustrated by Figure 1.5.

Figure 1.5 Interaction with the Local Procedure Call Facility

When an application makes an application program interface (API) call to an environment subsystem, the stub in the client (application) process packages the parameters for the call and sends them to a server (subsystem) process that implements the call. It is the LPC facility that allows the stub procedure to pass the data to the server process and wait for a response.

For example, consider how this process works in the Win32 subsystem. When a Win32 application is loaded to run, it is linked to a DLL that contains stubs for all of the functions in Win32 API. When the application calls a Win32 function (in this example, the CreateWindow Win32 function) the call is processed as follows:

1. The CreateWindow() stub function in the DLL is called by the client Win32 application.
2. The stub function constructs a message that contains all of the data needed to create a window and sends the message to the Win32 server process (that is, the Win32 subsystem).
3. The Win32 subsystem receives the message and calls the real CreateWindow() function. The window is created.
4. The Win32 subsystem sends a message containing the results of the CreateWindow() function back to the stub function in the DLL.
5. The stub function unpacks the server message from the subsystem and returns the results to the client Win32 application.

From the application's perspective, the CreateWindow() function in the DLL created the window. The application does not know that the work was actually performed by the Win32 server process (the Win32 subsystem), that a message was sent to make it happen, or even that the Win32 server process exists. It does not know that the subsystem called one or more Executive system servers to support its call to CreateWindow.