Tom Servo

Back to Profile: Tom Servo


  • Jeffrey Snover - Monad demonstrated

    Chances are that it might also be called "Windows Command Shell", at least that's what the preview setup file is called currently.
  • Joe Stegman - Developing rich user interfaces with Windows Forms

    ...and the WinFX betas when they start.
  • Joe Stegman - Building Outlook UI in 100 lines of code with Winforms

    Related topic: Why is the toolstrip support so simplistic in WinForms 2.0? And why are there no docking windows? All that stuff is available full-featured in WTL, but not WinForms 2.0.

    I'm currently using SandBar and SandDock from, but I'd rather have WinForms supply the same controls as WTL does.
  • Jamie Cool - Demo of ClickOnce

    Dumb question, are the premises (code and whatnot) for a ClickOnce install packed with the file that gets deployed on a webserver? Means, can anyone install a ClickOnce package without installing something else in advance?
  • Don Box - final part of Indigo team tour

    And when?

    I could swear that Indigo was supposed to be shipped way in advance of the rest.
  • Jim Allchin - The Longhorn Update

    LarryOsterman wrote:
    Secondly: WinFS IS NOT A FILESYSTEM!!!  It's a storage system for file metadata.  The WINFS store is a file in a directory on an NTFS partition.  It's NOT a filesystem in its own right.  You don't put files in WinFS, you put file metadata in WinFS.

    There's a BIG difference.

    It is a file system, you can put files into it, create folder structures, access the files thru UNC path. I've been copying images, music, text files and what not into the WinFS store of my Longhorn installation. They were INSIDE the store, I had to access them a la \\localmachine\DefaultStore\folder\anotherfolder\coolpicture.jpg.

    Ok, technically the filestreams go onto NTFS, but everything is abstracted by WinFS. At some later point this could very well change, and noone would notice (unless you're eagle eyeing your System Information Folder).
  • 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.