Article - PS WinAPI

PowerShell provides access to Windows API functions through .NET classes. It allows running managed secure code on Windows instead of unmanaged code. PowerShell users can access Windows API by working through the .NET framework. If desired functionality is missing, the Add-Type cmdlet can add the required .NET class and allow interacting with unmanaged Windows API functions through a .NET object.

Uploaded by

Rano Kravchenko

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

44 views2 pages

Article - PS WinAPI

Uploaded by

Rano Kravchenko

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 2

Interacting of PowerShell and Windows API

Human users need efficient ways to control computers, and command line using is one of such ways. The
command line accepts user-specified commands, processes them, and then transmits them to execute.
Previously, the commands were relatively simple, but over time, we needed increasingly complex commands
and scrips to automate repetitive tasks. Therefore, command-line processors have become more complex
and turned to what we now call a command-line shell.

In 2006, Microsoft released Windows PowerShell; this is a command-line shell that includes capabilities
of .NET framework. PowerShell is object-oriented, unlike file- and thread-based shells, which are commonly
used in a *NIX environment. Microsoft PowerShell provides authors of scripts with access to objects (class
instances) and their properties.

The .NET framework, released in 2002, has been declared by Microsoft as the recommended framework for
building applications and components for Windows. Accordingly, the PowerShell architecture was originally
designed to support the .NET ecosystem.

The most important component of Microsoft .NET is Common Language Runtime (CLR). With CLR, .NET
supports multiple programming languages – different modules of the same application running in the CLR
can be written in diverse languages. CLR has capabilities of compilation, data type checking, program
garbage collection, and secure code access. Code that runs in CLR and takes advantages of these CLR
benefits is called managed code. Accordingly, code that runs outside CLR is called unmanaged code.

Microsoft Corporation is interested in running managed secure code within Windows operating systems. For
this reason, .NET libraries include a large number (tens of thousands) of classes that contain many methods.
The programmer/operator has plenty to choose from, and it is a rare case when he has to use unmanaged
code.

One example of unmanaged code is DLLs of Windows API. Windows Application Programming Interface
(Windows API) is a set of predefined classes, functions, structures, and constants that any application can
use to interact with Windows OS. Windows API consists of thousands of functions.

Consider figure 1:

Fig.1 – Windows API DLLs are an example of unmanaged code

In figure 1, you can see that the code that runs on .NET platform is managed, and the code of Windows API
DLLs is unmanaged. Components of .NET are implemented as user-mode DLLs that are superimposed over
unmanaged Windows API functions. The OS kernel in this diagram is even lower. Neither the Windows API
DLLs nor the .NET components work in kernel mode.

Because the goal of Windows developers is supporting managed code, access to the Windows API through
PowerShell is done by the .NET (we are supposed talking about the officially recommended and documented
access method). Turns out that it is a kind of a "Russian doll": Windows system services are hidden in
Windows API DLL-library and Windows API DLL-library is hidden in .NET platform.

If a PowerShell user needs to access the Windows API, he works through the .NET. When does the need
arise? This occurs when the PowerShell cmdlets, functions, and scripts do not contain the desired
functionality. Here, the Add-Type cmdlet comes as the user's aid. Add-Type cmdlet adds the required
Microsoft .NET class to the PowerShell session. After that, the user can create object instances (using the
New-Object cmdlet) and apply the created object instances in the same way as any .NET object.