Just look at the public IDL files in the Windows SDK and look at what's inside #ifdef NTDDI_WIN7 blocks.

Hint: It's not a small list.

To what are you referring when you mention an equivalent to .htaccess?

Windows directory permissions are defined by ACLs (Access Control Lists) which are part of the NTFS file system. In Vista or later, this includes a Mandatory Access Control entry called an "integrity level" - defining which level of trust a process must have in order to access this file or directory.

Aside from ACLs, there should be nothing preventing you from accessing a folder.

This was primarily done to enable admin scripts (among others) to function on 64-bit versions of Windows without change.

A distinction I failed to make in my previous post was that unlike sudo, UAC doesn't run processes as a different user at all. Instead it runs them as the same Administrator user, but in a special security context which works as if the user were not an Administrator at all.

Further, I listed several ways in which UAC is unlike sudo. MAC, UIPI, and so on...

SELinux seems to bring some aspects of Windows' security model to Linux. But I haven't researched it enough to know exactly how close it's come.

UAC is quite different from su / sudo.

Windows NT has always supports the notion of "root" level (aka "Administrator") accounts and standard or limited user accounts. It has also long supported "runas" - the equivalent of sudo. The purpose of that is to allow a standard user to run a program in the context of another user, generally an Administrator, on the same desktop.

UAC, on the other hand, could be called the opposite of "sudo." Instead of running specific processes as a more privileged user, it allows an Administrator to run processes as a LESS privileged user, with varying privilege levels. Technically, Windows has also supported something like this in the past via Discretionary Access Control mechanisms and custom security tokens. UAC brings several additional pieces to the table such as: Mandatory Access Control, more direct user/system control over this behavior, and various bits of supporting infrastructure to make it both more secure (i.e. UIPI) and more compatible with existing programs (File System and Registry virtualization, for example).

UAC also allows programs such as IE and Chrome to run at below-standard privilege levels ("protected mode" or "sandbox" mode), enables secure consent prompts for elevation (more convenient and often more secure versus credential prompts which are vulnerable to spoofing attacks), and more.

So no, UAC is not a ripoff of sudo.

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.