Windows Vista Explorer Property System : The Windows Vista Explorer property system is being enhanced and extended. Some of the new features are:

• A rich and extensible property description system that provides information about properties to the Explorer (for example, display names and other attributes needed to present and operate over the properties).
• A stock list of well-known property types.
• A user interface (UI) that can edit your properties in different views like the list view, preview pane, property dialogs, and more.
• Property description lists, which define which set of properties are displayed in various views.
• A new interface (IPropertyStore) that allows read/write properties in addition to the previous read-only properties (IFilter). Typically, if you don't have large full- text content (such as media files), you can implement only IPropertyStore and still provide full-text content by using the full-text content property.

You can extend the metadata system by writing custom property handlers, protocol handlers, and even enable the system to use non-file system data stores.

Full-Text Search : Let's say that you'd like a user to be able to ask Windows Vista Explorer to find all invoices that contain a purchase of a particular product. Clearly, that information is locked up inside the invoice file somewhere, but Explorer needs some way to access it.

There are basically two types of data stores: file system stores and non-file system stores. The invoice example is a simple file system store. Explorer can search information in the invoice if a developer provides an implementation of the IPropertyStore or IFilter interface for this new file type.

Advanced Search now has some very interesting features like filters

If you're working with a non-file system store, you need to write a protocol handler that allows Explorer to navigate through the data store. A protocol handler connects the Explorer with a non-file-system-based proprietary data store. This enables the Windows search system to index data within the store. For example, if you have a mail client that stores its list of received e-mail, you can provide indexing and search capability for each individual e-mail by providing a protocol handler. Often developers who create a new protocol handler for a custom data source will also need to implement an Explorer Namespace Extension to provide UI for the items that are displayed in the Explorer, such as context menu handlers, icons, etc.

Extension Points : To extend Windows Vista Explorer, developers need to do two things:

1. Provide access to the internal contents of file formats and data stores.
   This enables Explorer to perform a system search across your file formats and data stores as well as file formats and data stores it inherently understands. Note that this enables Explorer to search not only the full-text content of your files but also its metadata. In addition, you enable users to organize their data by easily changing a file's metadata and saving the changes back into the file. The sample.invoice example in Figure 3 was all done by implementing a property handler.
2. Provide rich thumbnail view of individual files to Windows Vista Explorer.
   This enables Explorer to gain an idea of what is in the file directly from the Explorer view.

Developing Applications : Windows Vista supports a number of new APIs to use when developing new applications. Applications should never hard code file paths to "well-known" locations. Use Known Folder APIs instead. The Known Folder APIs abstract the file system location from the functionality of the folder. This allows features like folder redirection. You should use existing Known Folders when one is semantically equivalent to what you need, for example, PDF documents stored in Documents. Otherwise, your application can create new known folders, for example, 3D Drawings, Shapes, Code Projects, etc.

You can use new Windows Vista APIs to query items in the Windows Search Engine. Your application can use the OLEDB/ADO from managed or unmanaged code to issue queries using a SQL-like syntax. In return, your application receives an OLEDB Recordset where the columns correspond to properties in the Windows Metadata System, for example, System.Photo.FNumber.

You can also use the unified metadata layer to read/write metadata from/to file formats. Your application can enumerate properties stored in a file, discover property descriptions (schema) as described in the system, and read and write values for properties.

The Common File Dialog has been updated. It has a number of new COM APIs. Some of the new features of the Common File Dialog are:

• Enabling multiple view states per application.
  • View State: Last visited folder, dialog size
• Working with properties to:
  • Promote application-related properties.
  • Set default values for properties.
  • Get property values to save.
• Providing rich set of events: FileOk, Help, SelectionChange, FolderChange, Overwrite, and more.

The Common File Dialog is also extensible. You can add new controls and change the layout of the dialog.