Microsoft & Win32 API
The Windows API, or the Win32 API, forms the original platform for all native C/C++ Windows Applications, which require direct access to Windows, and hardware. The Win32 API Platform is best for all applications that require the highest level of performance as well as direct access to system hardware.
For setting up a Win32 API, all you need to do is the following: Download and update the Visual Studio. While installing the Visual Studio, do not forget to select the Desktop Development with C++ option.
For building Windows apps or other project types & app platforms, optionally select the .NET desktop development and the Universal Windows Platform Development while installing the Visual Studio.
For designing your desktop app into an MSX Package and debug or test the packaged app on the development computer, do not forget to enable the Developer Mode on your computer.
Windows API
The Application Programming Interface (API) of Windows allows all user-written programs to properly interact with Windows. It is an unwritten rule that all Windows programs except the console ones should interact with the Windows API. The most recent version of Windows API gets referred to as the Win32 API. To aid the applications that interact with the Win32 API, Microsoft maintains an extensive library of developer information.
As mentioned, the Win32 APIs provide powerful functionality that boosts the performance-quality of all Windows applications. All C and C++ developers get to readily access the Win32 APIs. Languages such as C# as well as Rust require bindings or wrappers for accessing these Win32 APIs. The bindings or wrappings used for C# are commonly known as Platform Invoking or P/Invoke. However, developers need to handcraft these wrappers or bindings, which is error-prone. Also, it does not scale to a broad API coverage.
Strong demands are coming from various languages to Microsoft regarding Win32 APIs. Hence, several community projects got spawned for providing more strongly typed wrapper & binding-representations.
The Win32 API Metadata
A Win32 API Metadata project got undertaken for providing a complete description of the Windows API in Metadata. This project helps Win32 API to be projected to any language in an automated way. Thus, the project helps improve correctness while minimizing the maintenance overhead. The project output is that it is effectively an ECMA-335 compliant Windows Metadata File (winmd), which got published to Nuget.org. The Nuget.org contains Metadata that describes the entire Win32 API surface.
As is known, the Win32 APIs have existed for a long time. Hence, describing the whole of Windows APIs will take some iteration. For this particular Win32 API Metadata to call the Windows APIs idiomatically from the language of their choice, all developers need language projections built on top of it. For instance, one such language projection is C#/Win32.
Apart from C#/Win32, Microsoft announced 2 more language projections as part of the Win32 API Metadata Project, which helps developers use the Windows APIs in any language. Looking at the C#/Win32 Language Projection, it parses the Metadata while generating the P/Invoke wrappers required for the Win32 APIs. The next language projection is Rust and it follows in the tradition established by the C++/WinRT for Windows using standard languages as well as compilers. It provides a natural and idiomatic way for Rust developers in order to call the Win32 APIs. The third language projection is the modern C++ Projection.
The Role of Microsoft in opening up old Win32 APIs
Herein, we are discussing how Microsoft makes Win32 APIs available to developers using any language. Microsoft is letting coders use languages of their choice instead of the default C/C++ option, by opening up old Win32 APIs used for Windows Programming. Win32 API is a 32-bit Application Programming Interface developed by Microsoft for Windows from versions 95 and later.
Windows System Architecture
As known, NTOSKRNL.EXE provides the basic functionality of Windows. However, it relies heavily on a Dynamic Link Library (DLL) referred to as the HAL.DLL. Hardware Abstraction Layer (HAL) is the code-portion, which allows low-level mechanisms such as interrupts & BIOS Communications in the Windows System Architecture. These are handled independently for ease of operation.
Herein, Windows System Architecture is considered as a layered one. The NTOSKRNL.EXE and HAL.DLL fall on the bottom layer. The layer above this consists of two important files referred to as NTDLL.DLL as well as WIN32K.SYS. The NTDLL.DLL consists of a number of user-mode functions known as System Call-Stubs & the Run-Time Library (RTL) Code. These are collectively referred to as the Native API. The RTL Code gets shared between NTOSKRNL and NTDLL. The WIN32K.SYS is a Kernel-Mode Driver, which implements the apt windowing and graphics that allow the user interfaces to be created.
The third layer from the bottom of the Windows System Architecture consists of several libraries. It consists of Win32 API. As mentioned before, the Win32 API includes all functions that a user needs to perform programming in Windows.
The Win32 API is categorized into four component parts. Each of these parts is a .DLL file. These are as follows:
Kernel32.DLL: It consists of a majority of the system-related Win32 API Functions, which are wrappers around the lower-level NTDLL functions. However, some functionalities including the National Language Support (NLS) & the Console Handling Area are unavailable in NTDLL.
advapi32.DLL: This DLL file includes all other system-related functions involving registry & service handling.
gdi32.DLL: All basic functions of drawing are included in this file. These relatively, simple functions allow users to draw any shapes on the screen.
user32.DLL: This DLL file consists of a number of functions that implement the familiar Windows user-face along with programs, message boxes, and prompts. These are implemented using the User32 Functions. It performs the tasks by a calling system, which is implemented by WIN32K.SYS.
C#/Win32
Now that we discussed and gained ample knowledge about Windows System Architecture as well as Win32 API, let us get back to the language projections starting with C#/Win32. This particular language projection got developed in partnership with Andrew Arnott, the owner of the P/Invoke Project done for .NET. For C#/Win32 to work, simply add a reference to the Microsoft Windows.Cs.Win32 Package from NuGet.Org. Also, add a file known as the NativeMethods.txt to the root of your project along with a list of Win32 functions that are required. The file contains one function per line, and wildcards such as BCrypt.* for involving the entire modules. Now, the C#/Win32 generates the P/Invoke wrappers for all the functions you request along with their dependencies. The language projection C#/Win32 showcases or highlights the possibilities of dynamically created projections for the Win32 APIs.
Rust
The second language projection is Rust Crate or simply Rust. It follows the tradition established by C++/WinRT of designing various language projections for Windows. It is known that the Windows Crate lets you call any Win32 API using various codes generated on the fly. These codes are generated from the Win32 API Metadata and enable you in calling the APIs as if they are a part of the Rust Module. The biggest benefit is that the Rust Crate does not attempt to partition Windows APIs by technology. Instead, it provides a single way to call any Windows API regardless of the underlying technology. With Rust, one can seamlessly make use of all Win32 APIs based on the C-Style Exports along with COM Interfaces or the WinRT Types.
Modern C++ Projections
The third language projection in addition to C#/Win32 and Rust Crate (Rust), is the Modern C++ Projections. Microsoft is working on these projections in the open on GitHub by welcoming community-contributions on developing these language projections there. These projects on the Modern C++ Projections are early previews that are under active development. So, it might be subject to significant changes as Microsoft keeps on working through feedbacks; thus making constant progress. As promised by Microsoft, they keep working with the developing community for supporting other languages that are based on demand, while partnering with any existing community projects where appropriate.
Conclusion
The Win32 API Metadata Project helps Microsoft hopes in advocating a clear set of principles, which all language projections should follow for the best developer experience. This process provides flexibility for each and every language projection for doing the best for the developer’s community. As per we discussed, Microsoft is taking all measures to make the Win32 API available for all languages. Making these Win32 APIs more accessible to many languages will undoubtedly help developers. The developers get helped as they get to utilize all the significant features provided by Windows regardless of their preferred language. As mentioned, Microsoft is excited to engage with the developer’s community for expanding the Win32 API coverage as well as proper language support by minimizing the maintenance overhead of all existing projects. These are the processes by which, Microsoft makes the Windows APIs or Win32 APIs available for all developer communities regardless of the languages they use or prefer.