My entry pointing
to our WinHEC slides resulted in links from quite a few sites and a ton of hits.
Top among these was an article on Slashdot.
Also notable are links from OSNews and Brad
Wardell (joeuser.com). In the last year my blog has gotten 20k hits (not
counting RSS reads). In the last day it has gotten something like 25k hits.
I'm sure that most of those 25k people won't be back to read this entry, but I'll
respond anyway.
I appreciate the attention and I've been trying to keep up with all of the comments.
Here are some notes and responses:
-
First off, I can't answer every question. I have no desire to get in to a flame
war over specific details or comparisons.
-
Avalon's
relationship to Direct3D: I tried to make this clear in the slides, but
it is worth repeating. We are building a managed presentation and UI layer on
top of Direct3D. While we will be exposing a 3D API, it is meant to round out
the UI story and integrate well with our 2D API. If you are doing super complex
3D stuff (FPS games), or want access to the latest and greatest Direct3D features,
Direct3D is the way to go. If you want to mix a little 3D in with your 2D, Avalon's
3D APIs will let you do that in a painless way.
-
Do
we really need the eye candy?: This has been a popular topic ever since we started
planning and talking about Avalon. I'm planning on posting something on this
later to start the discussion. My short take: I think that providing more capability
in the platform is a good thing that will make Windows a more attractive place to
write applications. I think that it will also allow our stock user experience
(Aero and the shell team) and application developers to push the limits and interact
with users in fundamentally better ways. However, with power comes responsibility.
We are working on a set of guidelines (these
are the Aero user interface guidelines) to help application authors use this stuff
in a consistent way.
-
The
3D bar graph demo is useless: I admit, this example is
useless as is. In a real application there will be a lot more UI about
picking what data you want to look at and how you want to look at it. The position
and view of the 3D graph would probably be controlled by the mouse so that you can
rotate things around to see hidden data. There would probably be different types
of graphs that you would switch between. However, this was meant as a demo application
that we threw together in a couple of days. While the application is a demo,
the platform that it is running on is real. There should be nothing stopping
someone from building a more industrial strength really usable version of this.
-
We
are behind the ball on 64 bit: While Windows had been compiling and shipping
(well, in beta to be clear) on 64 bit for quite a while (we handed out ia64 and x64
versions of Longhorn at WinHEC and via MSDN) the real call to action here was to IHVs.
Remember this was the Windows Hardware Engineering Conference. IHVs have
limited resources wrt writing drivers and we want to encourage them to write and maintain
64 bit drivers. This was one of the big pushes for the conference as a whole.
We don't want 64 bit uptake to be slowed down by lack of driver support.
-
The
longhorn requirements are crazy: I don't know where the requirements listed here
came from, but I haven't seen that list. Obviously we won't see that on a laptop!
There are a couple of things to note here.
-
First, we will run in software and on lower end machines. Things may run slower,
but it will run.
-
Second, we are going to offer multiple experiences based on hardware capabilities
and user preferences. This ranges from a classic view, to Aero to Aero Glass.
-
Third, the current minimum requirement for Aero Glass is a DX9 class card with 64MB
of video memory. More video memory will be required for higher resolutions or
multiple monitors. We also require the GPU to support PS 2.0 and have a LDDM
(Longhorn Device Driver Model) driver.
-
Fourth, as for processor requirements, most of the time when we have, in the past,
required a certain speed processor it has been because that speed has been an indicator
of the rest of the components in the machine (bus speed, hard driver speed, memory
speed, processor instruction support, etc.) The idea has been to use that one
number as a heuristic for
the "generation" of the machine. Hell, I've run Win2k3 server on a 400MHz celeron.
-
Lastly, we are really concerned about battery life and are working hard to
come up with a scalable user experience for times when battery life is more important
than running the GPU at full throttle. I believe that there are a bunch of slides
in Kerry's talk on that.
-
(my favorite) "dipshits
still can't code html/css?": I never claimed to be an artist, but the CSS in question
was my attempt to get a little bit funky with the style of my site. It is on
purpose. I assume that it will work in most browsers but, honestly, I only tested
it with IE and Pocket IE. I posted a response to
this on slashdot but apparently someone thought
I wasn't me. Too funny!
-
The
whole Apple transparent window thing: I don't read or comment on patents.
However, transparent windows have been around for quite a while. In the windows
world, these things were introduced in W2K with layered
window support. Other OSs may have had something similar earlier.
-
Longhorn
is just vaporware. I'll
believe it when it ships in 2017: I'm not crazy enough to comment on ship
dates. I'll leave that to the PR people and the execs. However, we are
showing off real code. We've publicly shipped two builds of Longhorn (the PDC
and the recent WinHEC build) along with SDKs. Not everything is done yet and
it is rough around the edges, but this isn't just slideware.
-
Innovation:
Innovation is such a loaded word. Hell, MS probably did more to make it loaded
than anyone else :). However, I never used the word on my blog and I don't know
where the guy who posted this to OSNews.com got it. It really touched off a
flamewar there which basically comes down to your definition of innovation.
Leaving that aside... I think that Avalon, and Longhorn in general, puts a lot
of very interesting features together in an integrated API that will benefit developers
and end users in very exciting ways. Use your own definition of innovative to
parse that last sentence.
Well, hopefully that runs the gamut. I probably missed some stuff, but I have
to get some real work done today.