Federated Search is a Windows 7 feature and did not exist in Vista.

Vista can query a remote Vista or Windows Search 4 index for a file share, but that's separate from the feature we call Federated Search, where Windows 7 can federate queries to OpenSearch enabled sources such as SharePoint, Search Server, FAST, etc.

Again you are incorrect on several counts.

The whole point of Federated Search is that the server is NOT running Windows Search. Instead it can be running SharePoint / Search Server, FAST, or virtually any other indexing solution. Lots of indexing solutions can output RSS or Atom over HTTP, or can be easily extended to do so. Then you get the same local file experience users expect from Explorer, but with whatever remote index you want.

Also, Windows 7 and Server 2008 R2 do not run WS4, they have a newer version of the indexer that *is* significantly faster and scales significantly better.

Actually it's quite relevant. Windows 7 can federate queries to a SharePoint or Search Server index using OpenSearch.

Also, Windows Vista and Win7 (and even XP with WS4 to some extent) can query remote Windows Search indexes. I use this functionality along with my Windows Home Server (running WS4) for my personal needs.

For indexing files, you're better off using Windows Search 4, a free download for Windows Server 2003. The old content indexing service is deprecated and a much older technology. It's useful in some particular scenarios but for a smaller (100,000 - 250,000 items*) corpus of file content, WS4 will work much better. And for larger repositories, SharePoint and Microsoft Search Server are almost always better options.

* = Server 2008 R2 / Win7 has a newer version of the Windows Search indexer that scales better to even larger corpuses.

Microsoft has a few solutions you can consider depending on your specific needs.

With Windows XP/2003, Vista/2008, or Windows 7 - you can install Windows Search 4 (not necessary on Win7, but recommended for Vista) on the server side to index the content, and then if you have WS4 (or Win7) on the client, it will automatically query the remote index when you perform searches against that file share.

Alternatively, if you run the free Microsoft Search Server (the Express version is free) which is based on SharePoint, you can index files on the server and then set up a Federated Search connector in Windows 7. Windows 7 supports federating to OpenSearch + RSS/Atom enabled sources, and SharePoint / Search Server support this. On current versions there's a bit of manual work to create the right OpenSearch description file, but it's pretty easy. The upcoming 2010 SharePoint version provides those out of the box (as well as some additional enhancements supported by Windows 7).

I'm actually the developer who built the OpenSearch feature in Windows 7, so if you have questions about the search options in Windows 7, you can visit my blog (brandonlive.com) and/or e-mail me (via my site).

Hope that helps.

If a site is standards-compliant right now and renders properly in IE 8 then it won't be added to the Compatibility View list.

If a site is standards-compliant but has improper version checks that break under IE 8, it may get added to the CV list until such time as the site is updated to handle IE 8 properly.

The X-UA-Compatible tag is mostly for sites that aren't on the list or otherwise want to force the IE 7 behavior. If they want to force IE 8 mode they can do that too, but there isn't all that much reason to. It certainly isn't required in order to get correct behavior.

Or were you just going for troll points there.

That paper was a joke. It was entirely made-up. It was thoroughly debunked YEARS ago and you're referencing it here? In 2009? Give me a break.

None of the baseless predictions made there turned out to be correct. It was an utter load of crap.

DRM has absolutely nothing to do with any performance issues you might see on Windows Vista.

When you copy a file in the shell there is absolutely, positively, ZERO code related to DRM that is executed. None. Zilch.

What would its purpose be? What would it accomplish? Can you provide an example of its effect? Of course not, because it doesn't exist. I work on the shell, I've seen all of that code. There's no secret DRM check. You can copy HD content via the shell til your heart's content and no DRM code will ever be executed. No messages will ever appear telling you to stop. Hell that's not even how DRM works. DRM schemes don't care how many times you copy the file, they just care whether your device is licensed at playback time. That's what WMP checks if you play DRM'd content. And if you play content in WMP that isn't DRM'd, then there's nothing to check. If you hate DRM, don't buy any DRM'd content, and there will be no reason for any DRM-related code to ever run on your machine.

You're just making yourself look foolish by repeating these baseless accusations. It's clear you don't actually *use* Windows or know anything about software, otherwise you'd know how ridiculous your claims sound.

My facts are 100% accurate. I should know, I work on the damn thing.

If you have something worthwhile to contribute then post it and stop trolling.

Just use the default view and type what you're looking for into the search box. Isn't that much easier than scanning the classic-view list?

Libraries don't help you segment your data, they help you bring it together from disparate sources. The whole idea is to *remove* the segmentation of your data by providing rich, metadata-based views backed by a fast database where you can search or pivot easily across any properties (including location) without regard for the physical location of the data.

I'm also confused what you mean about "OS-locked-in-way." The OS provides rich APIs for working with Libraries, but the definitions themselves are simple and (soon to be) well-documented XML format. What about that do you believe creates unnecessary "lock in?" What would you propose to make it better?

(Note that I'm a developer on the shell team, and am genuinely interested in how you think we could improve the interoperability story regarding Libraries)

You're making it sound like copying a file is as simple as reading from one place and writing to another. In reality, file operations are an incredibly complex problem.

A few points:

1) The shell doesn't just deal with files. It has a very sophisticated set of abstractions to support all manner of data sources. Whether it's WebDAV, SMB, HTTP, FTP, a portable media device, a third-party namespace extension, or a standard filesystem location - the shell has to support transferring data between each. Each can have its own set of requirements around naming, around alternate streams, around metadata support, conflict resolution, ACL / permissions information, error handling and resume support, and so on.

2) Read the link I gave in my earlier post. Windows XP used buffered I/O and also dismissed the copy dialogs before the operation completed. Vista changed this so that the dialog stayed until the operation completed and also disabled the use of buffered I/O. This offered some advantages, but in SP1 we moved back to buffered I/O because of customer feedback (and a lot of work to optimize its usage).

3) Vista does a much better job handling ACLs and maintaining permissions structures across copies and moves. But there's some small overhead introduced in order to accomplish this.

4) Vista introduced a lot of features around the "discovery" process before a copy or move operation begins. This process adds some additional overhead, but enables a better experience in other ways. For example, beginning in Vista the shell can now ask you upfront about conflicts that will occur. This prevents you from starting a large operation, walking away, and returning to find that as soon as you left the room the system asked you a question about one file at the front of the list, leaving all the other non-conflicting files waiting for your response.

In Vista, the shell will check every file for conflicts before it begins copying. And once it does begin copying, most errors it encounters (like a permissions or file-in-use error) will be deferred until every successful item is copied. Then it will prompt you at the END of the process for those which it was unable to handle without your help.

Now, there were some issues with this logic in Vista which caused it to be run unnecessarily (like on same-drive moves) or take more time than it should. SP1 made significant improvements to this, and as I said Windows 7 makes substantial improvements on top of that.

There are other complications I didn't cover here, like the fact that I/O is scheduled to ensure that media playback isn't interrupted and that the system remains responsive during these operations.

If you haven't built such a system, it's easy to oversimplify the problem and make it sound trivial. But that doesn't paint an accurate picture of what's going on. There are very few "simple" problems when dealing with software as complicated as an operating system, especially one with the scale and broad requirements of Windows.

Protected Media Path is NOT DRM. And it was included in Windows XP under a different name.

It is a platform service which enables application developers to meet the requirements imposed by certain content protection standards. It is in of itself completely unaware of any DRM schemes or media types.

It is also completely inactive and irrelevant until somebody's code calls the necessary APIs. Enabling PMP features doesn't impact performance, and the PMP code is ONLY run while an application is actively making use of it.

Windows Explorer makes no use of these features. Hell, its features (securing the audio / visual outputs and running decoders in a protected process) are completely inapplicable to the file browser. The only applications included in Windows which make use of it are Media Player and Media Center. And as I already said, even if you are running one of those applications (with media like BluRay which enables these features), there is no perceivable performance impact on your system.

If you really don't like the Protected Media Path services, nothing stops you from using a media player which doesn't make use of the PMP APIs. And the assertion that the presence of this platform service somehow affects file copy performance is proposterous.

Vista never had any DRM of any kind built-in, other than the DRM support in WMP that was in XP.

Certainly nothing at all that affects copy operations in the shell. That notion is absurd (I'm a shell developer, I would know).

It's just a ridiculous myth that gets repeated on Slashdot and nowhere else.