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.
And now I'll leave you with a screenshot of my desktop, a link to DesktopX 2,
and a video of me doing some cool stuff today and letting you imagine what cool
things you'll be able to make With DirectGUI technologies (what API underneath
DesktopX) in Avalon:
See you tomorrow!