Windows Shell

The Windows UI provides users with access to a wide variety of objects necessary for running applications and managing the operating system. The most numerous and familiar of these objects are the folders and files that reside on computer disk drives. There are also a number of virtual objects that allow the user to perform tasks such as sending files to remote printers or accessing the Recycle Bin. The Shell organizes these objects into a hierarchical namespace and provides users and applications with a consistent and efficient way to access and manage objects.

Shell Development Scenarios

The following development scenarios relate to application development:

• Extending the Shell, which consists of creating a data source (versus consuming the Shell data model)
• Implementing a subset of the Shell data source tasks
• Supporting libraries and item views in Windows Explorer
• Using the common file dialog
• Implementing Control Panel items
• Managing notifications

The following development scenarios relate to file format ownership:

• Implementing a subset of the Shell data source tasks
• Implementing any handler
• Supporting desktop search

The following development scenarios relate to data storage ownership:

• Supporting desktop search and OpenSearch
• Implementing a subset of the Shell data source tasks (virtual folders)
• Supporting libraries in Windows Explorer

The following development scenario relates to device support:

• Auto run and auto play

Windows Shell SDK Documentation

This documentation is broken into three major sections:

• The Shell Developer’s Guide provides conceptual material about how the Shell works and how to use the Shell’s API in your application.
• The Shell Reference section documents programming elements that make up the various Shell APIs.
• Shell Samples provides links to related code samples.

The following table provides an outline of the Shell Reference section. Unless otherwise noted, all programming elements are documented in unmanaged C++.

Windows Shell

The Windows UI provides users with access to a wide variety of objects necessary for running applications and managing the operating system. The most numerous and familiar of these objects are the folders and files that reside on computer disk drives. There are also a number of virtual objects that allow the user to perform tasks such as sending files to remote printers or accessing the Recycle Bin. The Shell organizes these objects into a hierarchical namespace and provides users and applications with a consistent and efficient way to access and manage objects.

Shell Development Scenarios

The following development scenarios relate to application development:

• Extending the Shell, which consists of creating a data source (versus consuming the Shell data model)
• Implementing a subset of the Shell data source tasks
• Supporting libraries and item views in Windows Explorer
• Using the common file dialog
• Implementing Control Panel items
• Managing notifications

The following development scenarios relate to file format ownership:

• Implementing a subset of the Shell data source tasks
• Implementing any handler
• Supporting desktop search

The following development scenarios relate to data storage ownership:

• Supporting desktop search and OpenSearch
• Implementing a subset of the Shell data source tasks (virtual folders)
• Supporting libraries in Windows Explorer

The following development scenario relates to device support:

• Auto run and auto play

Windows Shell SDK Documentation

This documentation is broken into three major sections:

• The Shell Developer’s Guide provides conceptual material about how the Shell works and how to use the Shell’s API in your application.
• The Shell Reference section documents programming elements that make up the various Shell APIs.
• Shell SDK Samples provides links to Shell samples. Most samples can be downloaded from MSDN Code Gallery. All samples are included in the Windows SDK.

The following table provides an outline of the Shell Reference section. Unless otherwise noted, all programming elements are documented in unmanaged C++.

What is PowerShell?

PowerShell is a cross-platform task automation solution made up of a command-line shell, a scripting language, and a configuration management framework. PowerShell runs on Windows, Linux, and macOS.

Shell

PowerShell is modern command shell that includes the best features of other popular shells. Unlike most shells that only accept and return text, PowerShell accepts and returns .NET objects. The shell includes the following features:

• Robust command-line history
• Tab completion and command prediction (See about_PSReadLine)
• Supports command and parameter aliases
• Pipeline for chaining commands
• In-console help system, similar to Unix man pages

Scripting language

As a scripting language, PowerShell is commonly used for automating the management of systems. It is also used to build, test, and deploy solutions, often in CI/CD environments. PowerShell is built on the .NET Common Language Runtime (CLR). All inputs and outputs are .NET objects. No need to parse text output to extract information from output. The PowerShell scripting language includes the following features:

• Extensible through functions, classes, scripts, and modules
• Extensible formatting system for easy output
• Extensible type system for creating dynamic types
• Built-in support for common data formats like CSV, JSON, and XML

Configuration management

PowerShell Desired State Configuration (DSC) is a management framework in PowerShell that enables you to manage your enterprise infrastructure with configuration as code. With DSC, you can:

• Create declarative configurations and custom scripts for repeatable deployments
• Enforce configuration settings and report on configuration drift
• Deploy configuration using push or pull models

Next steps

Getting started

Are you new to PowerShell and don’t know where to start? Take a look at these resources.

PowerShell in action

Take a look at how PowerShell is being used in different scenarios and on different platforms.

Windows commands

All supported versions of Windows (server and client) have a set of Win32 console commands built in.

This set of documentation describes the Windows Commands you can use to automate tasks by using scripts or scripting tools.

Prerequisites

The information that is contained in this topic applies to:

• Windows Server 2019
• Windows Server (Semi-Annual Channel)
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2
• Windows Server 2008
• Windows 10
• Windows 8.1

Command shell overview

The Command shell was the first shell built into Windows to automate routine tasks, like user account management or nightly backups, with batch (.bat) files. With Windows Script Host you could run more sophisticated scripts in the Command shell. For more information, see cscript or wscript. You can perform operations more efficiently by using scripts than you can by using the user interface. Scripts accept all Commands that are available at the command line.

Windows has two command shells: The Command shell and PowerShell. Each shell is a software program that provides direct communication between you and the operating system or application, providing an environment to automate IT operations.

PowerShell was designed to extend the capabilities of the Command shell to run PowerShell commands called cmdlets. Cmdlets are similar to Windows Commands but provide a more extensible scripting language. You can run Windows Commands and PowerShell cmdlets in Powershell, but the Command shell can only run Windows Commands and not PowerShell cmdlets.

For the most robust, up-to-date Windows automation, we recommend using PowerShell instead of Windows Commands or Windows Script Host for Windows automation.

You can also download and install PowerShell Core, the open source version of PowerShell.

Incorrectly editing the registry may severely damage your system. Before making the following changes to the registry, you should back up any valued data on the computer.

To enable or disable file and directory name completion in the Command shell on a computer or user logon session, run regedit.exe and set the following reg_DWOrd value:

To set the reg_DWOrd value, use the hexadecimal value of a control character for a particular function (for example, 0 9 is Tab and 0 08 is Backspace). User-specified settings take precedence over computer settings, and command-line options take precedence over registry settings.

Command-line reference A-Z

To find information about a specific command, in the following A-Z menu, click the letter that the command starts with, and then click the command name.

Launching Applications (ShellExecute, ShellExecuteEx, SHELLEXECUTEINFO)

Once your application has located a file object, the next step is often to act on it in some way. For instance, your application might want to launch another application that allows the user to modify a data file. If the file of interest is an executable, your application might want to simply launch it. This document discusses how to use ShellExecute or ShellExecuteEx to perform these tasks.

Using ShellExecute and ShellExecuteEx

To use ShellExecute or ShellExecuteEx, your application must specify the file or folder object that is to be acted on, and a verb that specifies the operation. For ShellExecute, assign these values to the appropriate parameters. For ShellExecuteEx, fill in the appropriate members of a SHELLEXECUTEINFO structure. There are also several other members or parameters that can be used to fine-tune the behavior of the two functions.

File and folder objects can be part of the file system or virtual objects, and they can be identified by either paths or pointers to item identifier lists (PIDLs).

Object Verbs

The verbs available for an object are essentially the items that you find on an object’s shortcut menu. To find which verbs are available, look in the registry under

HKEY_CLASSES_ROOT\CLSID\ \Shell\verb

where object_clsid is the class identifier (CLSID) of the object, and verb is the name of the available verb. The verb\command subkey contains the data indicating what happens when that verb is invoked.

To find out which verbs are available for predefined Shell objects, look in the registry under

HKEY_CLASSES_ROOT\object_name\shell\verb

where object_name is the name of the predefined Shell object. Again, the verb\command subkey contains the data indicating what happens when that verb is invoked.

Commonly available verbs include:

Verb	Description
edit	Launches an editor and opens the document for editing.
find	Initiates a search starting from the specified directory.
open	Launches an application. If this file is not an executable file, its associated application is launched.
print	Prints the document file.
properties	Displays the object’s properties.
runas	Launches an application as Administrator. User Account Control (UAC) will prompt the user for consent to
run the application elevated or enter the credentials of an administrator account used to run the
application.

Each verb corresponds to the command that would be used to launch the application from a console window. The open verb is a good example, as it is commonly supported. For .exe files, open simply launches the application. However, it is more commonly used to launch an application that operates on a particular file. For instance, .txt files can be opened by Microsoft WordPad. The open verb for a .txt file would thus correspond to something like the following command:

When you use ShellExecute or ShellExecuteEx to open a .txt file, Wordpad.exe is launched with the specified file as its argument. Some commands can have additional arguments, such as flags, that can be added as needed to launch the application properly. For further discussion of shortcut menus and verbs, see Extending Shortcut Menus.

In general, trying to determine the list of available verbs for a particular file is somewhat complicated. In many cases, you can simply set the lpVerb parameter to NULL, which invokes the default command for the file type. This procedure is usually equivalent to setting lpVerb to «open», but some file types may have a different default command. For further information, see Extending Shortcut Menus and the ShellExecuteEx reference documentation.

Using ShellExecuteEx to Provide Activation Services from a Site

A site chain’s services can control many behaviors of item activation. As of WindowsВ 8, you can provide a pointer to the site chain to ShellExecuteEx to enable these behaviors. To provide the site to ShellExecuteEx:

• Specify the SEE_MASK_FLAG_HINST_IS_SITE flag in the fMask member of SHELLEXECUTEINFO.
• Provide the IUnknown in the hInstApp member of SHELLEXECUTEINFO.

Using ShellExecute to Launch the Search Dialog Box

When a user right-clicks a folder icon in Windows Explorer, one of the menu items is «Search». If they select that item, the Shell launches its Search utility. This utility displays a dialog box that can be used to search files for a specified text string. An application can programmatically launch the Search utility for a directory by calling ShellExecute, with «find» as the lpVerb parameter, and the directory path as the lpFile parameter. For instance, the following line of code launches the Search utility for the c:\MyPrograms directory.

A Simple Example of How to Use ShellExecuteEx

The following sample console application illustrates the use of ShellExecuteEx. Most error checking code has been omitted for clarity.

The application first retrieves the PIDL of the Windows directory, and enumerates its contents until it finds the first .bmp file. Unlike the earlier example, IShellFolder::GetDisplayNameOf is used to retrieve the file’s parsing name instead of its display name. Because this is a file system folder, the parsing name is a fully qualified path, which is what is needed for ShellExecuteEx.