This week we published an update to the Federated Search Implementer’s Guide.  This update includes some new information as well as some corrections to the original document.  Most crucially, the original document erroneously indicated that the URL template contained an attribute called “format” – when it was referring to the “type” attribute.  So if you followed the guide exactly, your OSDX file wouldn’t work properly with Windows 7 (or anybody else following the OpenSearch spec).

This update also includes additions such as information about providing “collection” templates to display results without the user entering a query, details about URL protocol support, and more.

Link: Windows 7 Federated Search Provider Implementer’s Guide

The new page roughly sums up its use and purpose:

A client-side OpenSearch data source that sits in between the Microsoft Windows OpenSearch provider and the external data source.  With a search connector (a .searchconnector-ms file), Windows Explorer calls your implementation with the query parameters. Your implementation returns results formatted in RSS or Atom format. That allows your implementation to provide custom authentication UI and connect to the data source using its proprietary API.

More details at:  http://msdn.microsoft.com/en-us/library/dd378289(VS.85).aspx

Unfortunately we still don’t have any details on how you actually hook up an implementation of this.  The doc / SDK folks are working on this but it’s part of a larger effort that’s taking a bit of time.  In the meantime I’m going to see if I can post an example here or on CodePlex.  Most likely I’ll be posting a detailed .NET example followed by a simpler C++ version.

If you have questions about whether this API may end up being useful to you, let me know, and hopefully I can help clarify what is or isn’t possible.

Check it out and let us know what you think!

This document covers subjects such as crafting the best OpenSearch Description File for your site, returning files and custom properties, customizing the results view, optimizing your source for performance, and more. If you’re interested in developing an OpenSearch source for Windows 7, check it out! And as always, please share your feedback!

Link: Windows 7 Federated Search Provider Implementer’s Guide

General

Windows Explorer

Taskbar modifiers

Note that this list focuses on stuff that’s specific to Windows 7. For a complete list of Windows Vista hotkeys (which should be largely unchanged except where noted above), visit this page on Microsoft.com or look in the Windows Help file.

If there’s something you think I should add, post a comment!

It looks like a work-in-progress, and since his service works as a proxy to talk to Flickr, performance isn’t what it would be if Flickr had a native implementation.  But for something he threw together over the last night or two I’m impressed!

We’ll be talking more about Search Federation on the Engineering Windows 7 blog soon, and will have much more to share when we deliver the upcoming Windows 7 beta release.

Check it out!

In case you’re wondering which of the features unveiled at PDC is “my baby,” that would be the OpenSearch-based search federation feature in the Windows Explorer, detailed in the Find & Organize session which you can watch here.

We also have a Channel 9 video covering the new Libraries feature and other user experience improvements in Explorer for Windows 7.  This video is part 1 of a two part series, the second of which covers the Search Federation feature (and yours truly).

For now, the best place to learn more about OpenSearch in Windows 7 is to watch the session video at the link below.

PDC 2008 session – Windows 7: Empower users to find, visualize and organize their data with Libraries and the Explorer

This afternoon we made a follow-up post addressing some of the suggestions, comments, and concerns that showed up in the comments to the original entry.

If you have more feedback, please keep it coming.  I and others will try to respond in the comments over there, or in future follow-ups.

Also, if you like the gadget, please go to the Gadget Gallery page and give it a good rating

Download Indexer Status Gadget on Live Gallery

Windows 7: New APIs to Find, Visualize, and Organize

The presenter is my good friend David Washington, who is my team’s platform and SDK PM.  The talk will cover a variety of really cool topics, including my feature area which we’ll be talking more about soon.

If you’re going to be at PDC this year please leave a comment and share a bit about yourself and what you’re looking forward to seeing there. 

This afternoon Steven made his second post on the blog, discussing the Windows 7 engineering organization.  He describes the rough dimensions of the various feature teams, including a pretty complete list of the teams and an idea of their approximate size (ballpark estimate being 40 developers, 40 testers, and 20 PMs). 

If you look at his list you can spot my team, which goes by the name Find and Organize.  So who are we?  Well, as you might guess and Steven describes, we own the end-to-end Search features of Windows (the “find”) as well as the browsing and data management experience (the “organize”).  We often abbreviate this as “FnO” and many people pronounce it as “fff-no” (rhymes with “snow”), though I am not one of them.

Some examples of things we own:

• The Windows Search indexer
• The indexing configuration UI and the built-in filters / handlers
• The Windows Explorer UI, including things like:
  • The navigation pane
  • Address / Breadcrumb bar
  • Search box
  • Window frame
  • The Filesystem data source
  • The default Shell View (DefView), default Context Menu (DefCM), etc.
• The Explorer data source APIs (IShellFolder and friends)
• Known folders and APIs (”Documents” and such), recycle bin, shortcuts
• The common file dialogs
• Many/most of the Windows “common controls”
• Search in the Start menu

Whew, I often forget just how much stuff we own.  And my feature isn’t even on the list!   Oh yeah, did I mention we also owned the entire Windows Search 4.0 release?

We also aren’t the only team that “owns” the Explorer.  The Core User Experience team owns other pieces of Explorer like the taskbar and the rest of the Start menu.  You’ll often hear people from both teams refer to themselves as the “shell team,” or others refer to both teams collectively by that name.

So who makes up the FnO team?  Well, as I said, there are quite a few of us.  I’m certainly not the only one of us who blogs or has an online presence:

Jonas Barklund has a blog, he’s a developer whose focus is generally on query parsing.

Thayn Moore has a blog and is also a developer, and works on a bunch of stuff including, among other things, mail indexing.

Ben Karas has a blog and is a lead developer for most of the explorer UI.

Paolo Marcucci is a PM who doesn’t seem to blog these days, but posts on Channel 9 a lot.

I’m sure there are others I don’t know about.  So if you work on my team and have a blog, let me know.

As for me, well, you know where my blog is.  As for what I do every day… we’ll talk more about that soon enough.

Update: I saw a comment on Channel 9 ask about how we function with 40 developers on one team.  Well, the truth is these “feature teams” are actually divided into smaller teams that focus on closely related components.  So no, there isn’t really one manager with 40 developers reporting directly to him or her. 

Windam – I wonder why this would be released for Vista since search is already a well integrated feature to begin with.
Is it just because(optional)?

Maudit - Pardon my ignorance, but what the difference between Windows Search 4.0 and the one in Vista ultimate sp1, does it streamline into windows ?

A similar question was asked on Channel 9.

The answer is quite simple:

• Windows Vista includes “Windows Search 3.0″
• Windows Search 4 is an upgraded version of the indexer built-in to Vista.
• This release does not change the User Interface, it looks exactly the same.  The improvements are around responsiveness, resource usage, reliability, API support, etc.

A good analogy here might be DirectX.  Windows XP shipped with DirectX 8.1.  When DirectX 9 was released for XP, it didn’t change the way anything looked or behaved, but it made your system better.  You may apply a similar understanding to WS4.

• Faster queries, often several times faster
• Faster indexing / reduced resource usage
• Support for EFS (encrypted folders)
• Support for indexing delegate mailboxes
• Fixes for all the top reported Watson crashes / errors
• New group policy options

This release also adds the following Vista / Server 2008 features to Windows XP / Server 2003 systems:

• Remote query support (using the server’s indexed when querying a network share)
• Support for Vista-style preview handlers (Office 2007 documents, etc)

Read the KB article here for more details and complete feature list.

Download Links

Vista / 2008                    32-bit    |    64-bit

XP                                   32-bit    |    64-bit

2003 / WHS                    32-bit    |    64-bit

Vista users – don’t forget to grab the indexer status gadget!

IShellDispatch2 is one of the shell automation objects used to support scripting languages.  However, that doesn’t mean you have to use VBScript to gain some value from it.  In this case, IShellDispatch2::ShellExecute is exactly what we want, because it wraps the normal ShellExecute call but runs it from the context of the object implementing the interface – in this case, we want the IShellDispatch2 associated with the desktop shell.

Knowing this is only half the battle, though.  The next trick is to figure out just how to get to the right IShellDispatch2 object (the one for the desktop shell instance of Explorer.exe).

Fortunately, one of our architects, Chris Guzak (seen on C9 here), was able to point me in the right direction and connect up all the dots.

Our hunt begins with the IShellWindows interface, which can be used not only to reliably find the HWND for the desktop shell window, but also to get an IDispatch interface for it:

IShellWindows *psw;
    HRESULT hr = CoCreateInstance(CLSID_ShellWindows, NULL, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&psw));
    if (SUCCEEDED(hr))
    {
        HWND hwnd;
        IDispatch* pdisp;
        VARIANT vEmpty = {}; // VT_EMPTY
        if (S_OK == psw->FindWindowSW(&vEmpty, &vEmpty, SWC_DESKTOP, (long*)&hwnd, SWFO_NEEDDISPATCH, &pdisp))
        {

Next, we need the IShellBrowser interface, and we get that by querying for IServiceProvider and asking the SID_STopLevelBrowser service for an IShellBrowser interface.  And from there we can get the IShellView.

IShellBrowser *psb;

hr = IUnknown_QueryService(pdisp, SID_STopLevelBrowser, IID_PPV_ARGS(&psb));
if (SUCCEEDED(hr))
{
    IShellView *psv;
    hr = psb->QueryActiveShellView(&psv);

From there we need to get to that IShellDispatch2 interface that started this whole adventure. 

IDispatch *pdispBackground;
HRESULT hr = psv->GetItemObject(SVGIO_BACKGROUND, IID_PPV_ARGS(&pdispBackground));
if (SUCCEEDED(hr))
{
    IShellFolderViewDual *psfvd;
    hr = pdispBackground->QueryInterface(IID_PPV_ARGS(&psfvd));
    if (SUCCEEDED(hr))
    {
        IDispatch *pdisp;
        hr = psfvd->get_Application(&pdisp);
        if (SUCCEEDED(hr))
        {
             IShellDispatch2 *psd;
             hr = pdisp->QueryInterface(IID_PPV_ARGS(&psd));

At this point you should be able to figure out where to go from here.

If that’s not easy enough, watch out for Part 3 of this series in the next day or two.  It will contain a sample and describe how the Start++ installer makes use of it.