Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


Tom Servo Tom Servo W-hat?
  • Jim Allchin - The Longhorn Update

    Uh, Microsoft employees keep calling it Aero, and if you watched the video above with Jim, he also calls it the "Aero UI" too. So I don't think my naming conventions are wrong.
  • Scott Currie - Multiple language programming demo

    jsrfc58 wrote:
    Why couldn't someone write a single "universal" compiler, and then have interchangeable "front-ends" (scanner/parser/etc.)

    I think the Phoenix thing is kinda what you're thinking about.

  • Jim Allchin - The Longhorn Update

    I suppose for Joe Sixpack, the Aero UI will be spectacular enough, the previous Aero demos looked quite nice (but usually coupled with WinFS functionality, who knows what remains without it). It's not just the window borders that change. I just hope that the power users won't get the shaft, e.g. by dumbing down every dialog and settings application as much as possible.
  • Jim Allchin - The Longhorn Update

    There'll still be improvements in the fundamentals. Like a new printing subsystem, new and improved color management system, new audio subsystem, kernel improvements for realtime ops, new stabler driver model, and some other minor stuff. Then there'll be the Aero UI.

    But yeah, you can argue that you don't need all that, and in this case the question is warranted. But for instance Avalon on XP won't be that much the bomb, since XP doesn't have LDDM, which Avalon needs for stable hardware acceleration.

    And WinFS will still come for Longhorn, just a bit later. Doesn't mean it's out completely. Myself I'm still wondering how they want to ship it, and even more how they'll be integrating it. The first thing that comes into mind is that by installing WinFS, it'll replace the interim search tech that's going into Longhorn.

    Nice avatar btw!
  • Jim Allchin - The Longhorn Update

    Cool Smiley
  • Jim Allchin - The Longhorn Update

    The big slide makes it hard to read your comments, since I'm running the browser windowed. And what I said actually referred to text in a comment section of a blog of a MS employee, not this slide, though the post was related to it.

    And I don't see how I'm "not exactly wrong". Maybe I wasn't too clear with all that acronym soup, but the point I wanted to make is that the lower layer abstractions for XP and Longhorn will be different. On Longhorn the window surfaces will be handed over to the DWM (which is dependent on Avalon again) and on XP they'll be handed over to some code or application level glue that draws using GDI. Add some input handling thinking here. Additionally what I've wanted to say is that the UCE is an Avalon component afterall, since you made it sounds like it's a Longhorn thing only, and will be available in the XP version of Avalon, since it needs to composite the window surfaces, it's just not used for desktop composition.
  • Jim Allchin - The Longhorn Update

    BOFH wrote:
    stuff... DCE, DWM, Avalon, etc.

    Actually, there was a small discussion about that on Joe Bedas blog sometime ago.

    The gist: DCE doesn't exist anymore, it's been merged with the application layer compositor and is called UCE (universal composition engine). The DWM will thus use the same compositor as the Avalon application. And furthermore, the UCE _is_ part of Avalon. So Aero (Glass) requires Avalon in one way or another.

    BUT... the UCE can run in software mode. So it'll be likely that the WindowsXP build of Avalon will run in software mode inside the application, and some lower layer XP specific code will use GDI and User32 for display and input, instead of an desktop UCE on top of LDDM/D3D and whatever will do the input on Longhorn.

    Now regarding WinFS, currently it is built on top of NTFS, but since it currently also supports static folder structures defined inside the store, filesystem semantics are supplied. Thus I see no reason why you wouldn't be able to merge WinFS and NTFS for a post-Longhorn operating system (WinFS V2). Just drop an additional bitmap into the data file (next to the free page bitmap) that tells the filesystem driver which pages are used for data structures and which for filestreams. I'd rather want to see an unified filesystem than some piggyback thingymajic on longterm.
  • Jim Allchin - The Longhorn Update

    eagle wrote:
    after all Avalon and Indigo don't exist yet.

    Depending on how you see it. Exist? Yes? Out in the public? No. I've been writing two custom controls with Avalon already.
  • Scott Currie - Multiple language programming demo

    Too bad only link.exe can link modules. I'd like AL to be able to do so too, so I can use that from my custom MSBuild files.
  • Joe Marini - Why I love XAML

    It would be hard to make a standard, since XAML is more of a way to map the Avalon API into XML, not a strongly defined markup.

    But since we're again at Avalon and XAML, I'm wondering, did the stance about MDI in Avalon change by now? The last thing I knew was that it wasn't planned for 1.0, so developers would have to write their own MDI handler (wouldn't probably be too hard fiddling with panels, but it's all about getting system window borders and what not).