Microsoft Windows Search can be extended with add-ins to index the contents and properties of new file formats and data stores. If you have a custom file format, then you need to implement a filter or property handler to have file content and properties indexed. If you have a custom data store, then you need to implement a protocol handler so that Windows Search can access the data.

Windows Search currently supports the indexing of over 200 types of items (such as .txt, .html, and .xml file formats), and can work with a number of data stores (such as the NTFS file system and Microsoft Outlook). Windows Search uses filter and protocol handler technology similar to SharePoint Server. Hence if you already have implementations for your file format, then you can update the implementations to be initialized with a stream using IPersistStream for the filter to work with Windows Search.

This topic contains the following sections:

• Add a File Format
• Add a Data Store
• Add Web Server Data (Federated Search)
• Add-in Installer Guidelines
• Note to Implementers
• Related Topics

Add a File Format

Add-ins can extend Windows Search to index new or proprietary file formats, and to associate each new file format with a file-specific icon or shortcut menu. To do so, you can build and register filters to access the contents of the new file type, and property handlers to access the properties.

These add-ins implement the following interfaces:

1. An IFilter interface for each file type so Windows Search can access and index a file's text content.
2. An IPropertyStore interface for each file type so Windows Search, Windows Explorer, and other applications can access, and index a file's properties.
3. The IPreviewHandler interface for each file type so Windows Search can display previews of the files in Windows Explorer.

See the following topics for additional implementation details:

• About Filter Handlers in Windows Search and Best Practices for Creating Filter Handlers in Windows Search
• Developing Property Handlers for Windows Search
• Preview Handlers

Add a Data Store

Add-ins can extend Windows Search to index new data stores and to associate files from those stores with a file-specific icon or shortcut menu. A data store is a content source that can be described by a URL space representing a hierarchy or collection of URLs.

To ensure your data store in included in the Windows Search index, you can build and register a protocol handler that implements:

1. The ISearchProtocol and IUrlAccessor interfaces to process and bind individual items in the content source. Windows Search uses URLs to uniquely identify items, whether those items are in the file system, inside a database-like store, or on the Web.
2. The >Shell Namespace Extensions (Shell data sources), including the >IPersistFolder, >IShellFolder, >IExtractIcon, and >IContextMenu interfaces to add icons and shortcut menus so that those items can be present in Windows Explorer and Windows Search results views.

See the following topics for additional implementation details:

• Developing Protocol Handlers
• Implementing the Basic Folder Object Interfaces (for creating a Shell data source to support a protocol handler)

Add Web Server Data (Federated Search)

In Windows 7 and later, federated search offers a new search provider that queries remote data stores through Web servers, via the OpenSearch  protocol, and enumerates the results as RSS or Atom XML feeds. For more information about search federation to remote data stores in Windows 7, see Federated Search in Windows.

Add-in Installer Guidelines

Installation of an add-in should follow the following guidelines:

• The installer must use either EXE or MSI installer.
• Release notes must be provided.
• An Add/Remove Programs entry must be created for each add-in installed.
• The installer must take over all registry settings for the particular file type or store that the current add-in understands.
• If a previous add-in is being overwritten, the installer should notify the user.
• If a newer add-in has overwritten the previous add-in, there should be the ability to restore the previous add-in's functionality and make it the default add-in for that file type or store again.

Note to Implementers

Before creating a filter or property handler, developers should be sensitive to the following considerations:

• These handlers are in-process extensions loaded into processes that you do not control, such as the filter deamon process, Windows Explorer (grep search), and 3rd party hosts like Windows Mail).
• You must write secure code that is robust enough to handle arbitrarily corrupt forms of your file format created to attack the system.
• Your add-in must not leak resources that will produce problems for the host processes.
• Your add-in must not crash as this will also crash the host processes and slow down the filtering process.
• Because these handlers are run in a background system process, they must perform quickly with a minimum of CPU and I/O consumed in order to meet the performance requirements of the system.

Thus, these add-ins should be written by developers with expertise in creating system-level code.

Related Topics

• The Indexing Process
• Developing Filter Handlers
• Developing Property Handlers for Windows Search
• Developing Protocol Handlers