Today was the third day of Microsoft's Professional Developer Conference (PDC). The day was mostly broken up into sessions where developers could learn more about specific technologies.

Today I'll talk about two of those technologies into more detail. Now, my understanding about the advantages of some of this is sketchy and incomplete since we are, after all, talking about an OS that won't ship for 3 years.  Anyway, those two technologies are: WinFS and managed code in the form of the API called WinFX.

WinFS is not a file system. In fact, there is some debate about whether it is called Win File System or Win Future Storage. Regardless of what the acronymn stands for, WinFS will (not might, will) completely revolutionize the way we deal with our information.

Think about your hard disk for a moment. How large is it? 30 gigabytes? 50?  150?  There are 300 gigabyte hard drives either out or about to come out.  Imagine what they'll be in 2006. 3 gigabytes? And how do you store this data? In DOS-like directory structures like c:\documents and settings\myusernames\my documents\my music. My god that sucks.  Why are we doing that?  Apparently, someone at Microsoft had the same view and the solution comes in the form of WinFS.

So WinFS isn't a file system. Instead, it's more like a...layer on top of NTFS. One that provides database capabilities.  How advanced those capabilities will become will depend on three factors: (1) Security (2) Performance (3) Reliability.  They are often competing demands and so how powerful and neat WinFS will initially be depends a lot on how well the mesh with those 3 issues.

So what does that mean for real world use? Well, there is some talk about replacing folders with "stacks". Folders would remain but they would be tied to physical directory structures. Stacks would, in effect, be what users would slowly migrate to. Hopefully they'll come up with a better name.

So what kinds of things can we hope for in stacks? Well, one thing I would hope to see is that physical location becomes irrelevant. For example, tonight I have to update royalty reports, I messed up on the Stellar Frontier royalty report and need to make a correction. Okay. Great. Where did I put the royalty report?  If you're like me, the answer is, I'll do a search for 2Q2003.xls and it'll scan through my hard drive. If it's not here, then it's at work.

Idiocy.

With WinFS, that file would be located in a stack. I would have a bunch of default stacks and more would automatically be created as a generated content. The stack would automatically contain files from any device I have access to. That means my PDAs, my MP3 players, my work machine's main server, my work machine drives, etc. They would all appear in the stack without any concern for whether they were local or not. By 2006, I'll be pretty irritated if my net connection isn't at least 10 megabit (it's 3 right now).

Moreover, these stacks will be intelligent. That is, I would have a stack called "Royalty Reports". One would assume that the Longhorn save dialog will make it very easy to provide some basic classification at the same time so that they will automatically be added to existing stacks.  Now, for you database people, think of stacks as saved queries that dynamically update when a change is detected.

Combine this kind of organization ability with Avalon's compositing engine and you'll be able to display you data in all kinds of useful ways.

Note to Microsoft: Make sure you open it up so that third parties can add their own ways of displaying information and organizing it that appears equally "native". That means both visually and content-wise. So if I want to display family photos in a "Photo album view" and Microsoft hasn't provide a Photo Album view for displaying stacks, a third party should be able to create one and have it as an option at all times.

The second technology for the evening is WinFX. As I've talked to more and more developers, it's increasingly clear that few people are excited about WinFX. It's not that we don't want a cleaned up API for dealing with all this. The problem is that it's managed code. Managed code can mean many things. In this case, in Longhorn, you're really not talking to the part of Windows that does the work. You're talking to its front man.  A managed API is just a layer.  As a developer, I want to talk to the boss directly, I don't want to call its secretary and make an appointment and hope it's willing to do what I want.

Let me give you an example: API hooking. If everything moves to managed code, how do you hook an API? First, I better explain what the heck API hooking is. Or better yet, give you a LINK to someone much smarter than I am who can explain it more clearly. But in a nut shell, API hooking allows developers to replace parts of the OS with their own stuff.  Don't like the way scrollbars are handled in Windows? No problem, API hook them and take control of them yourself.  Microsoft forget to add some feature to the file dialog? No problem, API hook the file dialog and put in your own.  API hooking is the foundation of all good desktop enhancements. Without it, it's very difficult for a developer to extend the Windows base feature set in a way that's seamless.

But how do you hook a managed API? It's not even doing the job. You gotta talk to its boss which is underneath.  Now, managed APIs have a lot of good things going for them.  For one thing, a managed API is safe which means since Microsoft knows exactly what they can and can't do, they can make them available to scripting languages. This is a big deal to Microsoft because part of the goal of Longhorn is to merge the web and applications together via a super HTML type language called XAML. And using C# or whatever, you would then have access to any managed API right from a website. If you're at PDC, check out the Amazon.com booth.

The problem is, if Microsoft hasn't already thought of a feature or function in the OS, tough luck. There's no easy solution for this. Microsoft wants to eventually move to a 100% managed API architecture for support and future backward compatibility.  In Longhorn, at present, WinFX is a front end to Win32 and the new technologies.  Eventually though they want to be able to drop Win32 and the rest and be free to put whatever they want behind WinFX. That wouldn't happen for a long time.

Note to Microsoft: Please make sure there are ways for developers to be able to hook APIs in Longhorn in some clean non-hack way. Extensibility matters.

For companies like Stardock, we can always just write drivers that do this. There's always going to be a way around it. But looking back at the last 10 years, a great deal of innovation in software has come from individual programmers who have found some way to extend the OS to do something cool and new. 

WinFX may have a hard road as an API. For one thing, code written to WinFX isn't going to work under Windows XP or Windows 2000. Consider that -- by 2006, Windows XP will have been the shipping OS for 5 years. Windows 2000 even longer.  Point being, Windows XP is going to be the main OS people probably for the rest of the decade and that means Win32. So any barrier to WinFX could spell its doom. Developers are going to be forced to write to Win32 for years to come because of market realities.  So anything that makes WinFX less powerful than existing APIs is going to be a big negative.

So on the plus side, managed code lets you access a lot more power from more places. On the down side is it may make it much harder for developers to inherit and replace existing APIs.

So there you have it, 2 of the major new techs in Longhorn.  Tomorrow I'll talk a bit more about the importance of Avalon, XAML. In a nutshell: Vectors are cool and arbitrarily sized desktops are cool. Oh and one other thing: 16x9 is the future my friends. Wide screen! That's why the sidebar in Longhorn is such a big deal.