The Local Inter-Process Communication ( LPC , often also referred to as Local Procedure Call or Lightweight Procedure Call ) is an internal, undocumented inter-process communication facility provided by the Microsoft Windows NT kernel for lightweight IPC between processes on the same computer. As of Windows Vista , LPC has been rewritten as Asynchronous Local Inter-Process Communication ( ALPC , often also Advanced Local Procedure Call ) in order to provide a high-speed scalable communication mechanism required to efficiently implement User-Mode Driver Framework (UMDF), whose user-mode parts require an efficient communication channel with UMDF's components in the executive .
14-515: The (A)LPC interface is part of Windows NT's undocumented Native API , and as such is not available to applications for direct use. However, it can be used indirectly in the following instances: (A)LPC is implemented using kernel "port" objects, which are securable (with ACLs , allowing e.g. only specific SIDs to use them) and allow identification of the process on the other side of the connection. Individual messages are also securable: applications can set per-message SIDs, and also test for changes of
28-560: A Gopher , HTTP , or WAIS server, and includes Remote Access Service for remote dial-up modem access to LAN services using either SLIP or PPP protocols. Windows NT 3.5 Resource Kit includes the first implementation of Microsoft DNS . Other new features in Windows NT 3.5 include support for the VFAT file system, Object Linking and Embedding (OLE) version 2.0 and support for input/output completion ports . Microsoft updated
42-533: A heap to allocate memory from and the second and third because they use the console, accessed only via KERNEL32.DLL). The vast majority of other Native API routines, by convention, have a 2 or 3 letter prefix, which is: user32.dll and gdi32.dll include several other calls that execute an interrupt into kernel mode. These were not part of the original Windows NT design, as can be seen in Windows NT 3.5 . However, due to performance issues of hardware of that age, it
56-471: A transport when the client and server are both on the same machine. Many services that are designed to communicate only on the local computer use (A)LPC as the only transport through RPC. The implementation of remote OLE and DCOM in many cases uses (A)LPC for local communication as well. Windows Native API The Native API is a lightweight application programming interface (API) used by Windows NT 's kernel and user mode applications. This API
70-577: Is a major release of the Windows NT operating system developed by Microsoft and oriented towards businesses. It was released on September 21, 1994, as the successor to Windows NT 3.1 . One of the primary goals during its development was to improve the operating system's performance. As a result, the project was codenamed "Daytona", after the Daytona International Speedway in Daytona Beach, Florida . Windows NT 3.5
84-741: Is used in the early stages of Windows NT startup process , when other components and APIs are still unavailable. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API. The Native API is also used by subroutines such as those in kernel32.dll that implement the Windows API , the API based on which most of the Windows components are created. Most of
98-670: The AT&;T UNIX System V " STREAMS " API.) TCP/IP and IPX/SPX stacks in Windows NT 3.5 are rewritten. NetBIOS over TCP/IP (NetBT) support as a compatibility layer for TCP/IP was introduced as also the Microsoft DHCP and WINS clients and DHCP and WINS servers. Windows NT 3.5 can share files via the File Transfer Protocol , and printers through the Line Printer Daemon protocol . It can act as
112-463: The graphical user interface to be consistent with that of Windows for Workgroups 3.11 . NT 3.5 shows performance improvements over NT 3.1, and requires less memory. A lack of drivers for PCMCIA cards limited NT 3.5's suitability for notebook computers. To install Windows NT 3.5 on a computer that has a sixth-generation or later x86 processor, one has to modify files on the installation CD-ROM. In July 1995, Windows NT 3.5 with Service Pack 3
126-631: The Native API calls are implemented in ntoskrnl.exe and are exposed to user mode by ntdll.dll . The entry point of ntdll.dll is LdrInitializeThunk . Native API calls are handled by the kernel via the System Service Descriptor Table (SSDT). The Native API comprises many functions. They include C runtime functions that are needed for a very basic C runtime execution, such as strlen(), sprintf(), memcpy() and floor(). Other common procedures like malloc(), printf(), scanf() are missing (the first because it does not specify
140-426: The number of messages and threads. Additionally, ALPC messages can be batched together so as to minimize user-mode/kernel-mode switches. (A)LPC is used heavily in communication between internal subsystems in Windows NT. The Win32 subsystem uses (A)LPC heavily for communication between client and the subsystem server ( CSRSS ). Quick LPC was introduced in version 3.51 of Windows NT to make these calls faster. This method
154-522: The security context in the token associated with the (A)LPC message. The typical communication scenario between the server and the client is as follows: (A)LPC supports the following three modes of message exchange between the server and client: ALPC has a performance advantage over the former LPC interface, as it can be configured to use I/O completion ports instead of synchronous request/reply mechanism that LPC exclusively uses. This enables ALPC ports high-speed communication which automatically balances
SECTION 10
#1732798642170168-499: Was decided to move the graphics subsystem into kernel mode. As such, system call in the range of 0x1000-0x1FFF are satisfied by win32k.sys (instead of ntoskrnl.exe as done for 0-0x0FFF), and are declared in user32.dll and gdi32.dll. These functions have the NtUser and NtGdi prefix (e.g. NtUserLockWorkStation and NtGdiEnableEudc ). Uses of Native API functions includes but not limited to: Windows NT 3.5 Windows NT 3.5
182-584: Was largely abandoned in version 4.0 in favor of moving the performance critical server portions into kernel mode (win32k.sys). The Local Security Authority Subsystem Service (LSASS), Session Manager (SMSS), and Service Control Manager all use (A)LPC ports directly to communicate with client processes. Winlogon and the Security Reference Monitor use it to communicate with the LSASS process. As mentioned, Microsoft RPC can use (A)LPC as
196-635: Was succeeded by Windows NT 3.51 , released in 1995. Support and updates for Windows NT 3.5 was ended by Microsoft on December 31, 2001. Windows NT 3.5 comes in two editions: NT Workstation and NT Server . They respectively replace the NT and NT Advanced Server editions of Windows NT 3.1 . The Workstation edition allows only 10 concurrent clients to access the file server and does not support Mac clients. Windows NT 3.5 includes integrated Winsock and TCP/IP support. (Its predecessor, Windows NT 3.1, only includes an incomplete implementation of TCP/IP based on
#169830