Or the fact that Apple provides webkit as a core part of their OS's API set (upon which much of the included UI and apps are built)?
You act like history hasn't completely and utterly validated Microsoft's (ahead-of-it's-time) assertion that the web platform would be crucial to the future of computing.
Because the system requirements page says 10.6.3 is the minimum.
Actually it makes it so that IE can only worry about writing to D2D/DWrite and whether there's GPU acceleration or not is something IE doesn't have to worry about.
The changes to the API surface from Windows 2000 to Windows 7 are innumerable. You must be joking if you think the only change is transactional filesystem access.
Of course "you can get the same functionality." You could write the entire OS yourself if you wanted. But if you actually want to push things forward your best bet is to build upon the works of others, like the huge amount of infrastructure the Windows team has put into each successive release.
I told the recruiter that I didn't feel comfortable signing such an agreement since Microsoft works in so many different areas that there was no way to avoid some sort of conflict.
I'm not a lawyer, but my understanding is that the Microsoft agreement doesn't say what you just said. It says you can't immediately go work on *exactly the same thing* at a competitor. Plenty of people go off to work at competitors, they just work on a different kind of project for at least a year.
The same #define is used for all APIs/DDIs these days. Take a look at shobjidl.idl (shell interfaces) for example.
What could there possibly be in Windows 7 that Vista lacks?
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
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.
"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."
