RPC & COM foundations

Named pipes give you a channel; they don't give you a contract. RPC (Remote Procedure Call) is the layer that lets a client write ordinary-looking function calls while the actual execution happens somewhere else entirely — another process, or another machine — with the plumbing that makes that possible mostly invisible to both the caller and the person implementing the server.

The illusion, and what makes it work

A client calling an RPC interface writes code that looks like a normal function call: SomeManagementFunction(handle, parameter). What actually happens:

1. The call hits a client stub — code generated (traditionally from an interface definition written in MIDL, Microsoft's IDL) that knows exactly how to package that specific function's arguments.
2. Marshaling converts the arguments into a transport-neutral byte representation — necessary because the client and server might be different processes with different memory layouts, or even different machines with different architectures entirely.
3. The RPC runtime picks a protocol sequence — a transport — appropriate to the scenario: ncalrpc for same-machine calls (which typically rides on ALPC), ncacn_np for named pipes, or ncacn_ip_tcp for a genuinely remote call over the network.
4. A server stub on the other end unmarshals the arguments and calls the real, concrete implementation of the function.
5. The result travels back the same way, marshaled and unmarshaled in reverse.

The entire point of steps 2–4 is that the interface — what functions exist, what arguments they take — is defined exactly once, and the generated stubs handle every detail of getting a call across whatever boundary actually separates client from server. The application developer, on both ends, writes code as if calling or implementing an ordinary local function.

Local RPC is not a special case, it's the common case

A very large share of RPC traffic on any single Windows machine never leaves that machine at all: management tools talking to services, one system component talking to another, COM activation — nearly all of it uses ncalrpc or similarly local protocol sequences. This matters because it means "RPC" is not, in practice, primarily a networking feature Windows happens to also support locally — locally is the default case it's most heavily used for, with remote RPC as one option among several rather than the defining one.

COM: RPC with an object model wrapped around it

COM (Component Object Model) builds on the same underlying idea — cross-boundary calls that look local — but adds object identity, interfaces (in the COM sense: named, versioned contracts a component implements), and activation (finding or launching whatever process actually hosts the object you asked for). A COM call to an out-of-process server is, underneath, an RPC call to that server process; a COM call to an object hosted in a different machine (DCOM) is an RPC call across the network. COM's contribution on top of raw RPC is a consistent way to describe what you're calling (an interface, discoverable and versioned) rather than just how the call gets there.

A worked example: why a "local" API call can still be slow

A COM or RPC call that looks, in source code, exactly like calling a function in your own process can have wildly different performance depending on where the actual implementation lives: in-process (essentially free), in another process on the same machine (an ALPC round trip, still fast but not free), or on another machine (network latency, now firmly in the picture). This is precisely why COM distinguishes in-process, out-of-process (local), and remote servers as an explicit part of an interface's registration — the cost model genuinely differs, even though the call site in your code doesn't.

A common mistake

Assuming "RPC" implies "remote" is one of the most common misreadings of the term in a Windows context. The R in RPC describes the procedure call abstraction — that a call can be serviced somewhere other than where it was made — not a guarantee that "somewhere other" means a different machine. Most RPC traffic on a typical Windows system is local, transported over ALPC, and never touches a network at all.

Where this connects

• ALPC & local RPC is the transport underneath most of the local RPC traffic described here.
• The Service Control Manager is itself reached primarily through RPC — the control requests described in that chapter travel this exact path.