News 

This is part II of a two-part interview. Part I appeared on 17 June.

Q: What is the current status of Longhorn, and what is the latest anticipated release date?

A: We released a build of Longhorn at WinHEC, and that is available for people to use. We will have our beta 1 out this summer and beta 2 out following that and release the product sometime in the second half of next year for retail availability - both as a standalone package and bundled with machines in time for the holidays. We're following the same release model that we did for XP for the client. The server version will follow within a year after the client is released, with the same code base, but we take a little bit more time to get broad scale deployments on the server, and do some additional hardening of the server for specialized usage that we don't do on the client.

Q: What accounts for the delays with Longhorn, and which new features are proving difficult to design into (write into) the new OS? My question is in the context of Microsoft's stated goal of delivering a much higher level of security for the Windows OS. In practice, how difficult is it proving to design a secure OS?

A: When we set out to build Longhorn, we had some very ambitious plans about building a new software platform, and then using that exact same software platform to build major parts of the Windows infrastructure. The change we made about nine months ago was that we decided we were still building a new software platform, but that we wouldn't re-write all the major parts of the operating system to use that software platform. So we're still going to be delivering Avalon, Indigo, and WinFX for developers and we still have people that are building applications on those platforms that are fully supported, but the Windows shell won't be written on WinFX. It will still be written on a Win32 subset.

Most of the Longhorn features remain intact. We have a new networking stack that fully supports IPv6, we have the new Longhorn display driver model that changes the way that the operating system renders to the device, and so everything gets off-screen buffered, the video card does the overlay, you get a composited desktop where the windows can be blown up, animated, fades, transitions, wipes for any applications both new and legacy, and we are doing a ton of work in the security space.

In security in particular, we believe you can never have too much security. The key things we're doing in security is starting at the lowest possible level, with new ways of inspecting the code to remove buffer overrun, integer overflow and calls to so-called banned APIs, which are APIs that are likely to introduce problems with buffer overrun. These include string-processing APIs that in most systems are lurking in the background and have a tendency to lead to a possible buffer overrun.

So with Longhorn, we've adopted the philosophy that you can't put code into the system unless it passes our static and dynamic tests that are designed to check for integer overflows and buffer overruns and usage of the banned APIs. We're also going through all of our old code as well and doing the same level of cleanup that we are doing with the new code.

The other thing we're doing in Longhorn, is making an administrator on the system run with restricted privileges, so that if you're out browsing the web and running an application, the application doesn't have administrative privileges. If it then tries to do something that requires administrative privileges, there is a pop-up window that lets the user know that the application is trying to do something that it shouldn't.

As you well know, most users on Windows XP run with administrative privileges, and this is because the system didn't partition itself well. This is one of the legacies that were inherited from Windows 95. Windows NT, Windows 2000 and Windows XP all have the security built into them, but the problem is that in many of the applications that were designed to run on Windows 95, you have to relax the security in order for them to run, which meant that the people had to run as administrator. We're just getting rid of all the user level classifications in Longhorn. We have shimming and other capabilities that we've done with our applications like file virtualization, registry virtualization and other characteristics that allow applications that want to write to administrative parts of the system to think they are writing to those parts, while all along keeping those parts isolated and virtualized to the instance of that application.

In addition, we've taken Internet Explorer (IE) and we run that at an even lower privilege, along with all network interfacing applications so that if some piece of malicious code gets downloaded in IE, it has even less of a chance to affect your system. We've added registry protection so that critical registry keys can't be over-logged, we've added spyware and malware detection and protection into the system, inbound and outbound firewalls, network quarantine capabilities, and reduced privileges on services where we went through every service and downgraded many of the privileges previously held by many applications.

Beyond those issues, we've said that security is not just code quality or running at the right privilege, it is also preventing activities like phishing, which is definitely a security problem, by having IE tell the user that a link they just clicked on is not what it purported itself to be and there is a good possibility they are being phished. We're also doing other things in IE's user interface to try and educate people about the security issues that are out there.

Q: Are there any 32-bit parts in the current 64-bit Windows core? Which parts, if so? Will you have 32-bit parts in Longhorn core? Will there be a 32-bit version of Longhorn?

A: For compatibility, the WoW, or Window on Window system has 32-bit components, so when running in 64-bit, you actually need to deliver both 32- and 64-bit components because the APIs get dumped. We will continue to have 32-bit parts in the Windows core for two reasons, one to support compatibility, and two, to support legacy applications. For example, if an application needs the 32-bit MAPI.DLL for mail, it needs that MAPI.DLL to run normally. Another example is where there are legacy parts of the system, where you have end of life components, where they're just not going to be moved to 64-bit, they'll only ever run in a 32-bit environment. However, there should be no reason for an ISV, a manufacturer or customer to be running in 32-bit if the right device support is available for 64-bit. And yes, there will be a 32-bit version of Longhorn. Every day in our build-lab, we build three versions of Longhorn, x86, x64 and Itanium systems.

Q: There is some contradictory information about Longhorn's search capabilities. Using this chance, could you, please, say clearly whether or not Microsoft will integrate desktop and Internet search engines into Longhorn?

A: We have already made available to customers Windows desktop search and MSN search. This means that a customer can currently download the MSN search toolbar that includes a version of Windows desktop search that basically does the same thing that the Google, yahoo or Apple's spotlight on the Mac OS do, for Windows XP users today.

In Longhorn, what we have done is taken the concept of content indexing, which has already been in Windows for quite some time, and added property based indexing. And then we've also done two things in the shell, one is we've put a search box anywhere you are in the shell, which does filtering and fast search, full text search and property searches, and the second is that we've changed the way the shell works in that you basically build queries into the properties. For example, a user could write "show me documents written by John" and the result will look like a folder, but it is actually a running query. It uses the same index so it does not re-crawl the drive; it just goes to the indexer and requests the set of documents with the prescribed set of properties. So this is not just desktop search, it is an indexed property store with full text search and rich views based on the indexed store, and those properties will vary on the type of data. So for example, photos have metadata like the size of the picture, time it was taken, and maybe voice annotation; all of these get indexed. Music also has metadata like track numbers, names of songs, artists and that all gets indexed also.

For searching, we have different parameters for different types of documents, and we now have a system called live icons, where you actually have a high fidelity preview of what ever is in the document or folder.

Another thing we're doing is trying to change the way people think about this. Currently, people save documents all over the place, and what they really want is for the system to show them the documents regardless of where it was saved, so that's now a default view.

Q: Currently, word files backup automatically, and the user can set the delay as to how often the system backs up the document. However, more often, people just leave the default, and if they do have backups, there usually ends up being two or three versions of a document on your system. How will Longhorn help to address backing up or saving documents or application states if a system shuts down suddenly?

A: We've basically changed how the file system works in Longhorn. Functions like system restore and document backup are now handled by the file system. For example, when you save documents, the system will also save a version of the document in the background in the file system. This allows the user to use a function that gives them the capability to request an earlier version or versions of the document. This function already exists in Windows Server 2003 today and is being used. We took that same capability and applied it to system restore, so the way we keep restore points is to take snapshots of your system on a periodic basis, with the ability for the user to set the duration between snapshots. This function is also integrated with backup, so that if you have two drives on your system, and one is designated as the backup drive, the system can just snapshot deltas to the backup drive, so if your drive fails, the system can just restore your previous state from the other drive. The same back up procedure can be performed with an external drive as well, or you can burn CDs or DVDs that are snapshots of your back up, and all of this will be built into the Longhorn system.

Q: When drives or devices fail, and when my file system produces an error and needs to be restored, many of the messages and instructions are easy enough for me to understand, but for a person like my mother, these messages and instructions seem like a foreign language. What is Microsoft doing to help the less technical people understand and troubleshoot their system when failure occurs?

A: For some of the interfaces and messages, we have made them simpler. For example, we have system diagnostics in Longhorn that will detect when your disk is going to fail, and we know the common things that are going to happen to disks before they fail, and the system can now pop up a warning to your mom or other novice computer user that will tell them that their disk is about to fail, and that they should back up their system and would they like to back up now? If something catastrophic happens to your system, in the re-boot process we now have a recovery mode that will prompt the user to try a bunch of different solutions that will automatically be tried by the system for the user. An example of this would be the system first tries 'last known good' then it tries 'the back up' and then it tries 'system restore' and all of this is automated for the novice user. But there is only so much that can be automated, and beyond this, we have made it much easier for a technical user to help the person who is having trouble with their system over the phone. In this sense, you could lead your mother through the steps, one at a time, telling her how to accomplish the task of restoring the system.

Q: What has Microsoft done to facilitate remote control of a system so that the technical person can remotely log in to the system and fix it from a distance? Also, not just for Microsoft processes and programs, but for all applications on a remote computer, how can a person access these and help the novice user with his or her issues?

A: Remote assistance exists in Windows XP today, so you can go via remote assistance into your mother's system and help her to repair and or configure her system. The problem that exists today is the issue of firewall transversal with the remote assistance tool. With Longhorn, the system runs rendezvous services for the IPv6 network, so that you can do consumer-to-consumer firewall transversal. This functionality will work seamlessly in Longhorn, which is good for enabling voice, video, instant messaging and remote assistance. For other programs, we just use terminal server protocol between the remote and local computers. But if both users have Windows messenger, the user in need of assistance can application share through the program. With Windows Messenger or MSN Messenger, a user can open up a session and invite another user to use an application on their system and control that application remotely. The reasons we use Messenger is that you need consent to use those remote applications, and you need an IP address. So Messenger servers are used to do the rendezvous, and once the connection is established, what is left is a peer-to-peer connection, which is why you need firewall transversal. In the future, the system will use IPSec to secure the communication between the two terminals.

Q: Jim Allchin, Microsoft's group vice president of platforms, recently said the company is now seeing Longhorn as the basis of Windows releases for the next ten years. Can you explain if this is related only to desktop and server versions of Windows or to all Windows platforms including Windows Mobile and Windows Embedded?

A: In Longhorn, we'll do a desktop server and some subset of embedded roles like point of sale devices and applications like that. For broad scale embedded, we're just going to build a set of enhancements where we will take a set of capabilities from Longhorn back to XP embedded and rev that up. In the next version of the system, we'll eventually get back to one code base that does all things including embedded, desktop, server, mobile and any kind of fixed function device that manufacturers are building.

Q: Martin Taylor, Microsoft Platforms Strategist, and much more recently, Bill Hilf, director of Microsoft's platform technology strategy group, are people leading Microsoft's open source feeler programs (for lack of a better term). What exactly is the goal for Microsoft and this type of outreach? Will Microsoft try its hand at open source by releasing the source for some of its software under one of the open source licenses, like the Mozilla license?

A: We already provide source code with Windows CE, and it is freely available for people to use, change and put into their products under Microsoft's shared source license. But the situation regarding source code lays out a set of challenges that we have been working through. First, people are not really well educated on open source. You have to identify what open source license is the license they are talking about? Is it GPL, is it shared source, Apache or Mozilla? What are the specifics of the license in question? Is it a FreeBSD-like license?

Any license we do will never be, or include any thing from GPL, because we're a software intellectual property company, and GPL is a non-intellectual property license. You cannot contribute and retain your patent rights, and you cannot consume GPL code, and add your own code while preserving your intellectual property rights.

GPL aside, Microsoft is currently trying to decide what makes sense in terms of sharing source code. We already have government and large enterprise source programs, and we're working on some sort of academic deal for licensing source from our systems. This means that Microsoft is starting to think about how it will license its source out more broadly. Microsoft is taking code bases like Windows CE and just putting the whole thing out there to see what happens and how the community responds. This is a good metric for Microsoft in being able to see if customers get some value out of this, and if Microsoft will get the value back.

Q: Will the GUI (Graphical User Interface) remain a part of the Windows core? Will future versions of Windows begin to modularize the UI components?

A: Our embedded product already has that, which is part of the standard way that we handle that product. That being said, there are properties about the Windows architecture that don't allow that loose coupling to happen, and we are working on those for development efficiency. Now our client that we choose to package and go to market with will always come with a GUI because it is an important part of the experience to the customer. We feel that the consistency of the GUI is as important as the consistency of the API set, in that there are no re-training costs, easy to choose multiple vendors, easy to run it yourself, easy to choose applications and have them easily fit in. In the embedded space, we'll let people license embedded, put their own GUI on it, basically do whatever they want, but for our go to market products, we say that there is a collection of value associated with it that includes the GUI, and that is part of the license.

Q: Many servers in the industry run headless, that is, without a monitor, keyboard or mouse connected, these servers usually don't need a GUI because they are always remotely administered and they operate more efficiently without a GUI to take up CPU calculations. Is Microsoft working on giving administrators the option to strip the GUI off of these types of servers?

A: One of the things that we are addressing in Longhorn, and have invested a significant amount in componentization so that the user can do roll-based server distribution where your storage server doesn't have a GUI, only a command shell. We want to keep the option open for all different types of implementations, so if you want a storage server and nothing else, we'll have a license for that, and if you want a server with more functionality than just that of a storage server, you can license Windows Advanced server.