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.