Jim Allchin - The Longhorn Update

The Discussion

• 

  I agree - tough decisions were made.  But it's good that they made them.  Assuming Longhorn were to be unchanged, we'd only get a client OS in 2007 with lesser versions of all the new features.  Now we get a solid OS in 2006 and 2007, and the cool features get to be backwards compatible.  For an independent/hobby developer like me, waiting two or three years is a lot like waiting three or four.  It's still way in the future, so another year to me is just a drop in the bucket so to speak.
  
  I'm a little angry that there's no WinFS in Longhorn anymore, but the fact that you guys aren't going to release it until it's totally done (and that you haven't clipped it entirely) makes me happy again.
  
  Like I said - tough decisions that had to be made.  Here's to the Longhorn team for having the guts to make them!
  

• 

  That's the first I've heard about WinFS shipping later than Longhorn.  Sad news, to be sure.

• 

  Thanks for coming on channel9 Jim!
  
  Jim didn't look too comfortable, must have been giving interviews all afternoon. Most of what he said sounded like spin, after all Avalon and Indigo don't exist yet. Jim should get out in the sunshine more often, he has a boat doesn't he?

• 

  I'm just curious about what language are the "pillars" written in. Avalon, Indio, WinFS are exposed through WinFX. Since WinFX is a .NET assembly, can we assume that all the pillars are going to be written in C# ?
  

• 

  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.
  

• 

  In all software-projects there is a tradeoff to be made between time, features en resources.
  
  It seems that they have had a large number of requests to make Avalon available to Windows XP/2003. That means making a trade-off, with a delay for WinFS as the result.
  
  Especially the use of WinFS on an enterprise-level seems daunting. If I had the choice to 'skip' one of the pillars, I would probably choose WinFS as well.
  
  Would this mean that the PDC for 2005 is pushed back also?

• 

  I don't think the folks from WinFS will be working on the backports of Avalon and Indigo.  WinFS was very slow to make progress between the PDC and WinHEC builds of Longhorn, and I'd imagine those guys need all the time they can get just to have WinFS ready a short time after Longhorn is available.

• 

  Minh wrote:

  I'm just curious about what language are the "pillars" written in. Avalon, Indio, WinFS are exposed through WinFX. Since WinFX is a .NET assembly, can we assume that all the pillars are going to be written in C# ?
  

  
  
  Well they are for a big part in manage code, and MS just love C# so we can assume they are written in large part in c#... For source, look on this site and the .Net Show (https://www.msdn.microsoft.com/theshow/)
  
  And I suppose that the avalon and indigo part for XP will be release at the same time that Longhor beta
  
  
  
  Compugab

• 

  OMG he have black eyes , is he some kind of vampire or something *j/k*
  

• 

  I can assure you, I have had 1/1's with Jim during the day time, so I think that rules out this theory.
  
  You are going to make me nervous about my makeup for my next Ch9 video!
  
  -eric

• 

  There has been talk wondering if Microsoft's recent emphasis on transparency and feedback was only for show.  In my opinion, backporting Avalon to Windows XP is an unimpeachable answer in the negative.
  
  By the way -- thanks.

• 

  Wow!!! First of all... I'd like to think MS is doing the right and wise thing here...
  
  However if WinFX (including Avalon and Indigo) are going to be available for WinXP and Win2003.  What is going to be the point of Longhorn? mainly now that I came to know that (as I read on neowin.net) Longhorn is going to be builded from the WinXP SP2 source code, instead of the Win2003 code.  Do I already have 50% Longhorn? (I've got SP2)
  
  Now I know MS is NOT a bunch of jerks, What are going to be the other benefits of upgrading to Longhorn, besides the future WinFS add-on?

• 

  Alex Keizer wrote:

  In all software-projects there is a tradeoff to be made between time, features en resources.
  

  
  You forgot the 4th tradeoff: Quality...
  

• 

  Thanks for the Video. I also am curious if Avalon, Indigo and winfs are going to be available for windows xp Pro and 2003 Server, why will I Want to buy longhorn? Thanks for your time, Mr VP. you look very VPish. I Very much enjoyed your presentation, even if it was a little stiff. you did well. Applause.

• 

  It’s a little saddening to see LH be in such limbo but the decisions made were unavoidable if we really wanted to see LH in this decade.  The idea of bringing Avalon and Indigo to XP is a great idea since it will give XP a much needed refresh.

• 

  Porting back Avalon to Windows XP/2003 is misguided attempt.  Even though would be "available" for download, few would choose to download and install it.  And thus, it would only be guaranteed that Longhorn users can run Avalon applications.  For example look at .NET Framework 1.0/1.1, few average users have it on their computers, and it has been "available" for few years now.

  Besides, Avalon would need powerful machine, and graphics capabilities, which most XP machines (including those bought in 2001 when XP came out) do not have the muscle to make Avalon shine.

  Indigo on XP/2003 is good idea, as a common communication infrastructure across all windows machines, but Avalon on XP/2003, big mistake.  It will only add to complexity and consume time and resources from other more important developments.
  

  I am questioning how many people would benefit from Avalon on Windows XP?  Yes, there maybe some now saying “cool”, but two years from now – hardware will change, and many probably will get new PC with Longhorn in the box.
  
  As for Avalon on Server (2003), it is not that essential. Probably if you got Server 2003, one is using not for the esthetic looks, but rather for hosting varies services.  If someone wants full power of Avalon (mostly power-users) then they would get Longhorn.

  Microsoft move forward, not backward.
  

• 

  Maybe the backport of Avalon will be a version that is compatible with xaml, but wont include all the new graphical Aero stuff that longhorn has.

• 

  ZippyV: actually Jim Allchin told us that Aero will ship on Longhorn in 2006. So, you don't need Avalon for that.
  
  But, you're hinting at that some of Avalon was going to target Graphic Processors (not much, but some) and those parts are gonna be tough to port downlevel (after all, XP doesn't require a GPU and drivers on XP aren't always of high enough quality to rely on for something that'll be used in mission critical applications). What's the story there? Not sure yet. I think we'll need to re-interview Chris Anderson and get the scoop.
  
  But, XAML and Avalon will still ship with quite a bit of new graphical stuff. That was pretty clear from what Allchin discussed with us yesterday.

• 

  WinInsider: I disagree. I've already seen Avalon running on XP and it runs pretty darn well on underpowered machines.
  
  I also disagree that average users aren't getting the .NET Runtime. There's more and more stuff that uses the .NET system. My dad, in fact, downloaded it on his system just last night and it took him five minutes to get it. Very popular apps like NewsGator and Sharpreader require it.
  
  How many will benefit from Avalon on XP?
  
  Well, that's like asking "who will benefit from Macromedia's Flash or Adobe Acrobat?"

• 

  >why will I Want to buy longhorn?
  
  Let's revisit this next year when the beta ships. Then we can have a good discussion about whether or not they are enough for you to consider buying it (or develop on it).
  
  That said, these are some of the things +I+ am hearing from the marketplace:
  
  1) Fix my spyware/malware/virus problems (usually they don't even call it that -- on the plane yesterday my seatmate asked "how do I get rid of these stupid pop-ups that happen every 20 seconds?"
  
  2) Improve performance of my system. Why does it get slower over time?
  
  3) Improve the Tablet and/or portable features. Why does it take five seconds or longer to start up off of sleep mode? Can you make boot times faster? Can you make the wireless features even nicer? Can you make battery life longer?
  
  4) Can you improve the experience? Heck, I was at the San Francisco Apple Store today and overheard someone say "this [Macintosh OSX] looks so much cooler than Windows."
  
  5) Can you improve my media experiences? More and more people have video cameras, digital cameras, cell phones with cameras, audio devices like iPod or Rio's, and soon Portable Media Centers that'll play video and music. Yet creating, moving, editing, and playing video and music doesn't feel good. Heck, while playing Jim's video I clicked on the full screen button and the video stopped. Can't we solve that?
  
  6) Can you improve the browser? It hasn't improved in years. How about tabs? Standards? All the stuff that's been discussed over on the IE Wiki on Channel 9?
  
  7) RSS is changing how we consume information. It comes to us now, rather than making us "surf" to a site. Why isn't RSS built into the system?
  
  8) Bittorrent is changing how many of us can share files with others. I'd like to do that kind of thing with my friends safely and legally, especially since my camcorder's videos are too big to email or put up on most servers now.
  
  If we did most of the above, would that be interesting to you?
  
  If not, what would get you interested?

• 

  Eric Rudder: we don't allow makeup on Channel 9. That way we can separate the geeks who hang out indoors coding Longhorn from the guys who go out and play golf with clients.

• 

  The problem is, Scoble, some people are still unsure as to exactly what "Avalon" is, and very few people realise that Avalon isn't the hardware acceleration layer which Explorer Glass rests upon.
  
  Since MS have been, officially, very quiet about DCE - even at the WinHEC and PDC events - some people still fail to understand that whilst Avalon is the "presentation layer", it isn't the rendering engine which Explorer Glass is built on. That function still comes down to DCE, which will not be backported to XP.
  
  Sure, XAML apps and whatever will be able to run on Windows XP, but they won't offer any of the transparency effects present in the various 4074, 4067, 4050, etc, demos which have been shown at events such as PDC - all of those effects are powered by DCE, a separate entity from Avalon.
  
  The concept of backporting Avalon and Indigo down to Windows XP is to allow cross-platform compatability between Windows XP and Windows Longhorn. Microsoft were originally slated for their decisions to make Longhorn apps non-backwards compatible, and many saw this as one of the killing blows Microsoft were dealing upon themselves. Unfortunately, there were only two alternatives:
  
  1) Throw away the ambitious plans for Longhorn's new application model, and in the process throw out any of the new sandboxing and security features which are the #1 REASON for going with Avalon as the primary development system, or
  
  2) Backport the Avalon and Indigo stacks to previous versions. Since most people associated Avalon with the new current GUI shown at PDC and WinHEC, Explorer Glass, when to be perfectly honest it's merely a new application execution environment and/or API for native Longhorn software - somewhat akin to Windows.Forms. Just as the .NET Framework introduced Windows.Forms to Windows XP, as the replacement for MFCs, WinFX will introduce Avalon.
  
  Of course, Avalon apps, when executed under Longhorn, with the LDDM installed and enabled, will provide all of the DCE hooks required to enable Explorer Glass and the rest of the DCE effects generated by DWM.
  
  To round it all off, a glossary of terms/acronyms:
  
  DCE - Desktop Composition Engine
     Powers all of the new transparency and alpha blended effects shown at techdemos and enable-able in 4074/3718.
  
  DWM - Desktop Window Manager
     Enables all of the above effects - uses DCE as the rendering device for said effects.
  
  LDDM - Longhorn Display Driver Model
      Provides hardware support for the graphical effects rendered by DCE. Passes rendering of the desktop to the GPU rather than the legacy rendering method, GDI, used in the XP Driver Model.
  
  WinFX - Windows Framework Extensions?
        New API/programming stack which includes the .NET Framework as a subcomponent, as well as the Avalon and Indigo pillars.
  
  Avalon - Replacement For Windows.Forms
         Provided by the WinFX programming stack.
  
  Indigo - Web Services
         Replacement for things like Winsock, MSHTML, etc. A centralized location for developers to access live, non-local data.

• 

  I really want to know how you can ship a file-system after the fact. Really, can you imagine if NTFS had been shipped in Windows 2000 SP2.
  
  I think this new file system sounds like a load of rubbish but that isn't really the point, you can't release it as another update and expect people to just update their systems. Not to mention that if they do this update and use their original installation media to re-install they will lose their data!
  
  In *my* opinion you should drop it from the longhorn client completely. Don't even try and release it later. The server version is fine but make sure it isn't a patch and is there for us on release day.
  
  Hardcore release dates means they will drop some testing or re-testing. So when you first boot longhorn make sure to run Windows Update because I guarantee there will be something waiting for you.
  
  This thing might go belly up; I can definitely see that happening. People might look back and say 'If Microsoft had delayed but taken the time to make a solid product they wouldn't have lost to Linux' - This has happened before, go google for OS/2. And everyone knows history repeats its self.

• 

  BOFH: interesting, I didn't think that Glass needed the DCE. Allchin, yesterday, announced that Glass will be on the 2006 version of Longhorn.

• 

  Manip2: WinFS was never a replacement for NTFS, it always sat on top of (and used) an existing file system.
  
  So, it could be shipped later. Very easily.

• 

  As to OS/2: that failed because there weren't any applications for it.
  
  Here's a hint: Longhorn will run all apps that run on Windows XP. Lots of apps means that OS/2's problems won't revisit. At least Longhorn won't fail for those reasons.

• 

  scobleizer wrote:

  As to OS/2: that failed because there weren't any applications for it.
  
  Here's a hint: Longhorn will run all apps that run on Windows XP. Lots of apps means that OS/2's problems won't revisit. At least Longhorn won't fail for those reasons.

  
  
  But Linux can run XP apps..
  
  Anyway not too many people cared about porting their 16bit apps from 3.x, if OS/2 wasn't so buggy we could be using that right now instead of XP. OS/2 did come out first after all.
  
  

  scobleizer wrote:

  Manip2: WinFS was never a replacement for NTFS, it always sat on top of (and used) an existing file system.
  
  So, it could be shipped later. Very easily.

  
  
  Yeah, but the question is.. will an installation not writen to support WinFS be able to handle it on the system?
  
  PS: way WAY too many posts, consolidation!

• 

  >PS: way WAY too many posts, consolidation!
  
  Sorry about that.
  
  I liked OS/2, but it didn't run any of the apps that I wanted to use. So, I turned it down. Remember, I was a Mac bigot back then. So, I wasn't tied to the Windows OS, but I did need my OS to run some standard things (Adobe Acrobat, for instance, and Microsoft Office).
  
  Linux can't run all XP apps. Certainly not well.
  
  >will an installation not writen to support WinFS be able to handle it on the system?
  
  Yes, of course! Old apps were always going to be able to run fine on Longhorn. That's exactly one of the reasons why they chose the architectural direction for WinFS that they did. Can you imagine what would happen if only Longhorn apps could run on Longhorn?

• 

  Very well defined BOFH.
  
  If you had a look at some of the Architecture Presentations from PDC '03, you'll notice a diagram that shows you the WinFX architecture.
  
  On the top left, under "Client Application Model", you'll see listed two items. The first one says "Avalon and underneath that is System.Windows" and right next to it states "Windows Forms and underneath that is System.Windows.Forms".
  
  And then further down you will also see what is actually defined under the Presentation layer, the top most of which is explanation of what is in that System.Windows (and I suspect that is what Avalon is all about, correct me if i'm wrong...)
  
  I'll list all that is listed under what I understand will be for Avalon...
  
  First Branch: UI Element, Documents [Under Documents is: Text Element], Shapes [Under Shapes is: Shape], Ink.
  
  Second Branch: Explorer, Controls, Dialogs, Sidebar, Notification, Navigation
  
  Third Branch: Media [Under Media is: Animation], Controls [Under Controls is Control and Panel], Design.
  
  I'd show you a diagram if I could find the one i'm looking at online. Unfortunately I can't, however you can still download the powerpoint presentation and have a look yourself. (Would be much easier to understand).
  
  The link for the powerpoint presentation i'm looking through right now is here. And a list of all the other available power point presentations is available on the Sessions page from PDC 2003.
  
  Also I recommend checking out the CLI391 session presentation.
  
  Definately have a look through many of the presentations for more information.
  
  Although some of the information presented in those slides are no longer quite accurate, but they are still quite relevant nonetheless.
  
  If you don't want to go through them all, just read the ones that say they are related to Longhorn. The two i've listed are quite informative. [Though, that is coming from the perspective of a .NET developer...].
  

• 

  To me, from a business standpoint, I think these decisions make a lot of sense.  And, I also believe this video does a good job of explaining the "logic" behind certain decisions.  I would like to see more videos like this that explain the "logic" behind certain software design decisions, also...such as, "this is why a particular feature was built this way, and this is why we didn't do this, this, and this, etc."

• 

  AT wrote:

  I've expected this. Separating Windows Servers and Windows Clients has clear bussiness benefit for Micorsoft (read: more money collected!)

  
  
  I think you're reading too much into that.
  
  You'll find that they've always intended to release seperate client and server versions of Longhorn.
  
  It is like many other Windows OS releases, multiple versions for diffrent purposes. Eg: Windows XP Home and Windows XP Professional. (Not sure, but they may still offer that level of seperation). And also there was no XP branded server edition, instead we have Windows Server 2003.
  
  With Windows 2000, it was 2000 Professional, 2000 Server and I have a feeling there were a few other Windows 2000 branded releases, but those are the only ones that come to mind at this point in time.
  

• 

  I've expected this. Separating Windows Servers and Windows Clients has clear business benefit for Microsoft (read: more money collected!)
  
  This motivation similar to one used for separation of Winter and Summer Olympics.
  
  This is pretty smart move.
  Microsoft already releases their software on annual basis. Service packs always add new features (in constast with legendary "no new features in service packs" promise).
  But pay-us-for-upgrade versions ('major' releases) become rare.
  This is smart move to separate client and server releases in different financial years. This way business can pay twice (once for clients and once more for servers).
  
  I think that Microsoft will have to release Service Pack (free upgrade) for Longhorn clients in the same time they release Longhorn Servers.
  Just like in was for WinXP SP1 and Windows 2003.
  
  As for trimming features - this was expected taking in account announced delays. They were able to release Service Pack or stand-alone applications for WinXP/2003 with new technologies or bundle part of them in new (but trimmed from original expectations) OS version. They decided to do both.

• 

  will wrote:

  
  
  With Windows 2000, it was 2000 Professional, 2000 Server and I have a feeling there were a few other Windows 2000 branded releases, but those are the only ones that come to mind at this point in time.
  

  
  
  You forgot about Windows NT 4.0 Workstation, Windows NT 4.0 Server, Windows NT 4.0 Terminal Server Edition.
  As well version of Windows NT 4.0 Option Pack vs. Service Packs !!
  
  Go back to history plz ..
  
  I believe that Windows 2003 Server is in reality Windows XP Server (or Windows 5.1 Enterpise Server, Windows 5.1 Server, Windows 5.1 Workstation, windows 5.1 for Kids 

• 

  The Channel 9 Team wrote:

  
  3.) We originally planned to ship a new data storage system codenamed “WinFS” when we released the Longhorn Client. In order to deliver Longhorn’s innovations to customers as quickly as possible, we now intend to deliver WinFS after the initial availability of Longhorn client.  We continue to be committed to WinFS.  It is expected to beta when Longhorn client is broadly available.

  
  
  What does this mean for Longhorn? It won't be there at first, but then it will be added later.
  
  Will it mean that in the first release we can say good-bye to the file stores such as contacts? (I was really getting excited about some of that stuff).
  
  Secondly what does it mean for Longhorn after WinFS is out and about? Does longhorn then become complete, as in it will then have all its intended 'pillars' (was it three or four pillars)?
  
  I can wait an additional year for WinFS, but there is very little point to it if I cant get the same (or better) user experience that I could have if winFS did ship with Longhorn in '06. I see the intergration with windows (as if it had been shipped w/Longhorn) as important - Windows itself, from explorer to msn, to the photo editor, needs to fully exploit it.
  
  Maybe most of the stuff that is exciting to the end user can be done without WinFS, I really dont know. However it would be apperciate if what this meant for Longhorn (with and without WinFS) was explained.
  
  My $0.02
  Dave

• 

  Other Longhrn features I would like to see on Windows XP. 
  
  MSH.
  
  

• 

  A very tedious and stressful interview but it's still better than the choreoform pretensions of Ellison or that Cisco guy from Cat on a Hot Tin Roof.
  
  The delay of WinFS is a bitter tart but I am very, very tired of premature products patched up with "service" packs. WinFS is a historical watershed in technology. It is Microsoft's formal attack on the problem of the hard drive as described by The Father of Visual Basic ("the hard drive is a hack...").
  
  Microsoft, take as long as you need to come correct.

• 

  If you look at how WinFS is (to be) implemented, you can see how this would work.
  
  First off, WinFS is built on top of NTFS. Legacy files formats and things you would want to keep as files such as streaming video are store as NTFS files. Certain folders on that NTFS are designated as WinFS stores, and the system watches those folders very closely and keeps the metadata for those files synchronized with its own database, kept somehwere else. WinFS items could also exist in that database without any representation on NTFS (like SQL records in a table).
  
  If one had to install Longhorn 2006 from the orginal install disks onto a NTFS drive that once had WinFS stores, I could see the following happening. The database for those stores would be a file or files somewhere in the NTFS laying dormant. Legacy files and such would still be there in the directories. The metadata might get out of sync if you started editing those files, but this is unlikely as you would probably want to apply all the SP and whatever to get your WinFS functionality back. At that point, WinFS could pick up your old databases, resynch the metadata if needed, and you'd be back in business.
  
  Also note that WinFS stores are meant for user data. OS and application files would not be in WinFS stores. The OS would run fine before the WinFS SP was applied.
  
  Think about it this way. If you put a bunch of stuff in SQL server or MSDE, and had to reinstall the OS, you'd lose all of your data, until your reinstalled SQL server (or MSDE).
  
  At least that's the way I look at it.
  
  

• 

  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.
  

• 

  scobleizer wrote:

  BOFH: interesting, I didn't think that Glass needed the DCE. Allchin, yesterday, announced that Glass will be on the 2006 version of Longhorn.

  
  
  Well, of course it will; Lab 6 are currently well on track for a 2006 release of a finalized version of DCE, and LDDM support from the major video IHVs is quite forthcoming. Many of the DCE demos we've seen so far have been on either nVidia Quadro cards, or ATI's 9800/9700 range, with LDDM drivers powering the effects. Unfortunately, if you even so much as mention LDDM to an IHV, you'll recieve nothing but a "no comment" in response, which at least shows that they're taking it seriously.
  
  Glass, as well as the rest of DCE, including hardware acceleration, WILL be in the 2006 release of Longhorn, although it's still not certain whether or not the new shell which MSX/UX have been working on will be included (integrates things like GroupBar, ProjectBar, etc, into the standard windows shell, thus redefining the taskbar concept. The new shell, "AERO", will apparently be a consolidation of various MSR projects which showed productivity improvements over the standard Windows interface, and will also include simplification of various key UI elements, to make the overall Windows User eXperience (Aero), much more productive.
  
  WinFS
  As far as WinFS goes, to think of it as a radically redefined file system is to look at it in the wrong way. A better, and easier to understand model is of Windows XP's Indexing service. Basically, the Indexing Service provides a centralized database for rapid searching on Windows XP platforms. Or, as MS put it:
  
  Indexes contents and properties of files on local and remote computers; provides rapid access to files through flexible querying language.
  
  Basically, WinFS extends the functionality of Indexing Service to include metadata stored when an application creates or modifys a document, and is tracked in real-time and updated as and when it is required. Because of the enormous hit on resources this could - and will - have, upon the first index of a large hard drive, the idea eventually will be to have the process performed across a network by a centralized server running Longhorn Server, and then users would then be able to access that centralized store to search for documents on their own - and other people on the same domain's - computers.
  
  The client-based WinFS distribution was pulled from LH partly because they wouldn't have been able to achieve all of their goals by 2006, and partly because of the immense performance hit that everyone was reporting on all of the leaked builds seen by the Beta Scene over the last couple of years. At first, Microsoft weren't too worried about the state of WinFS in the early leaked builds, because an RTM release seemed so far away, anyway. However, when they released the PDC build, and STILL saw insane resource usage, that caused a re-evaluation in the development focus, and surprisingly, WinFS was one of the components which was most worked on for the release of Longhorn 4074 at WinHEC.
  
  However, WinFS's resource usage was still an issue - albeit not as much of an issue as with 4051 - and therefore after the completion of Service Pack 2, and all of the recent press as far as yet ANOTHER delayed release of Longhorn - Microsoft were forced once again to re-evaluate their development process, and decided to put WinFS off until the Server version shipped, thereby allowing the client-server metaphor for WinFS to work effectively.
  
  What does this mean for end-users? Well, they won't be experiencing a performance hit when installing Longhorn. This is a good thing, guys, because it means that Longhorn really will offer performance BENEFITS over Windows XP, and will offer yet another reason to upgrade.
  
  Also, it gives the development team more room to work on things like DCE, Avalon, Indigo, etc; the overall user experience will be much better in Longhorn when compared to either XP or 2000, something which is highlighted best by the new graphical effects and hardware acceleration present in even today's alpha builds of Longhorn. (3718 didn't require LDDM drivers, 4074 does)
  
  But yes, to answer your question Scoble, Glass is reliant on DCE's rendering/compositing features.

• 

  Tom Servo wrote:

  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.
  

  
  
  Ah, apologies there Tom; I'd forgotten about the change in acronyms to UCE. Yes, here's the slide you're referring to:
  
  
  
  You're not exactly WRONG, as far as the XP-delivered UCE goes, except there's one important distinction to make. Yes, Avalon will run in software mode, but it won't deal with the entire display - only Longhorn-style Avalon applications will have their controls rendered by UCE, and also, DWM won't be present, therefore the applications will lack graphical effects such as transparency and shadows, as well as windows Transition effects (spin to taskbar, spin to desktop, etc).
  
  Thanks for pointing this out.

• 

  "You forgot the 4th tradeoff: Quality..."
  
  Let's call that a feature

• 

  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.
  

• 

  Tom Servo wrote:

  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 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.
  

  
  
  Ah, okay, I get you now.

• 

  Cool
  

• 

  Do I miss something ??
  
  With Avalon and Indigo on my XP machine and no WinFS into Longhorn, gimme one good reason to buy LH in place of sticking with my Win XP ???

• 

  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!
  

• 

  According to Jim, the beta will start as soon as LH is broadly available.... probably not before 07 I suppose...
  
  The Aero UI is already available, not the real one but a nice GUI
  
  I agree with you concerning the new printing subsystem, the new color management system, new audio system...but what about Jim Doe ? Is he going to pay for an new OS without any spectacular improvments ? Especialy if he needs a new box to have it running...I'm not sure at all...
  
  
  And, yes, I like the avatar
  
  Cheers

• 

  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.
  

• 

  Hi there!
  
  Can you all stop calling it the Aero UI, please? It helps if you get your naming conventions right.
  
  It's called "Explorer Glass", not "Aero" anything.

• 

  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.
  

• 

  Perhaps Jim should have said "the Aero compliant UI", then
  
  Aero is a set of User Experience guidelines; not a UI. The new shell, which hasn't been demoed yet (and now, in light of the cutbacks, may not be included until Blackomb), is called AERO.

• 

  Comment removed at user's request.

• 

  Zeo wrote:

  
  
  I’ll leave with this one last question, having listened to PM’s and Devs I’ve heard them taking about the cutting of features for longhorn and their placement into the Blackcomb client OS, so what’s up with Blackcomb? What’s the developing story between the new Shorthorn, and the Long-term Blackcomb?  If features are being cut as they inevitability will in software development projects, what’s research working on for the post ’06 Client OS story?
  
  

  
  
  This is where I get to have fun
  
  Okay, basically, nothing's really changed... if you go back far enough. Back during the Whistler beta, the roadmap was quite simple - Whistler, followed by Blackcomb. The specifications for Blackcomb were laid down, UI prototypes and concepts were created and demoed at the Financial Analysts meeting by Steve Guggenheimer, and Blackcomb was all set to become the next major client release of Windows. Then, XP went RTM - later than expected, but earlier than Windows .NET, and Microsoft had a problem. They panicked, and threw everything into the development of Windows .NET, and by 2003 they'd finally got a product which was ready for release to the general market. By now, they were already rapidly approaching the estimated release date for the next client version of Windows (previously expected at 2004), and so they were forced to think again about their development plans.
  
  The upshot of it all was, that Longhorn was inserted between Whistler and Blackcomb as a point release; a minor update which would include some of the new features of Blackcomb, but miss out larger, key parts, such as the radically new GUI. This decision was made during the development of Windows Server 2003, and it was announced by various news sites that Longhorn would become the next client release of Windows. Of course, all this talk of a "radically new GUI" led people to believe that it would be... (omgwtfbbqgrass)... three dimensional. They based these opinions on various things being passed around at the time, such as the Task Gallery MSR prototype, and various other things such as 3DTop, SphereXP, etc. Unfortunately, these ridiculous claims also made some "reputable" news sites, and so it was clear as day that Blackcomb would contain the new 3D GUI. Ugh.
  
  Anyway, Windows .NET (now known as Server 2003), went RTM, and development on Longhorn was back on; full steam ahead as far as Longhorn was concerned. Then, something confusing happened. Microsoft announced "PDC '03", and various PowerPoint presentations were released which listed WinFS - which some people recognized as a continuation of Cairo - as one of the key components of Longhorn, along with Avalon and Indigo. This took everyone by surprise, as it was previously thought to be a Blackcomb feature.
  
  Okay, so lets take stock of where the roadmaps sit at this point (before PDC03):
  
  Windows XP - went RTM in 2001.
  Windows Server 2003 - RTM'd in 2003
  Longhorn - projected RTM, 2005
  Longhorn Server - projected RTM, 2007
  Blackcomb - projected RTM, 2008.
  Blackcomb Server - projected RTM, 2010
  
  Okay, so we've got two clear product cycles here - Client and Server. Both client and server releases are separated by 3 year gaps - plenty of time to work on each OS, devoting 1 year of dedicated time to client, and 2 years to Server, with up to two years overlap between the development cycles. Since server typically contains more components than client, this makes sense.
  
  Now, two things happened. Firstly, Microsoft announced that no; Blackcomb would not be the next MAJOR release of Windows - reasons for this? Well, they wanted Longhorn to sell for one, plus, a lot of the Blackcomb-only features were now being included in Longhorn, including an ehanced GUI. Of course, there's still internal promise of a RADICALLY new GUI, called "AERO", which nobody outside of MS has actually seen yet (that's what those UX and MSX boys are busy doing in Lab_06/private).
  
  The second thing was Windows XP SP2.
  
  Normally, development of service packs after SP1 is left down to the support team, but in the case of SP2, since so much extra functionality was added, development was handed back over to Windows Core - something which was previously unheard of. Basically, Longhorn development slowed to a crawl, and Microsoft realised that they weren't even going to hit their revised estimate of 2006. In order to ship WinFS along with the rest of Longhorn, it would take them up to 2007 or 2008 at least, and this was simply too long to wait for another client release of Windows.
  
  In August 2004, after Windows XP SP2 went RTM, Microsoft made the careful - and immensely wise - decision to revert back to the original roadmap, with Longhorn being a stepping stone to Blackcomb, the next major client release of Windows, which just happens to include WinFS, and a radically new UI called AERO
  
  In Bill Gates' interview with C|Net, he states that "the big breakthrough, where you get [WinFS, Avalon, Indigo, and AERO] brought together, will ship first off-cycle but then come back around and be built into the next OS release."
  
  That, ladies and gentlemen, is the future of Windows, and we're now (almost) back on the original roadmap, albeit delayed by a year because of Windows XP SP2.

• 

  Manip2 wrote:

  I really want to know how you can ship a file-system after the fact. Really, can you imagine if NTFS had been shipped in Windows 2000 SP2. 
  

  
  
  First off: NT's had a robust IFS model since NT 3.1.  It was designed into the original product.  So there's no technical issue with shipping a filesystem after the product.  I believe that NT 3.1 filesystems still run on XP (they might not, don't quote me on this one).
  
  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.
  

• 

  Are Google now going to have a huge advantage over winFS? Shame really - I value a usable file system over fancy UI.

• 

  Andrew Davey wrote:

  Are Google now going to have a huge advantage over winFS? Shame really - I value a usable file system over fancy UI.

  
  
  It's not a file system. :\

• 

  scobleizer wrote:

  3) Improve the Tablet and/or portable features. Why does it take five seconds or longer to start up off of sleep mode? Can you make boot times faster? Can you make the wireless features even nicer? Can you make battery life longer?

  
  
  That would be cool. Most of this can be considered Intel's territory through.
  
  

  scobleizer said:

  4) Can you improve the experience? Heck, I was at the San Francisco Apple Store today and overheard someone say "this [Macintosh OSX] looks so much cooler than Windows."

  
  
  Too bad Macintosh OS X is designed to look cool rather than be easy to use.
  
  

  scobleizer said:

  8) Bittorrent is changing how many of us can share files with others. I'd like to do that kind of thing with my friends safely and legally, especially since my camcorder's videos are too big to email or put up on most servers now.

  
  
  Personally I'd rather see you guys improve MSN Messenger's file transfer feature to work efficently in a non-UPnP environment rather than use Bit Torrent for point to point file transfers. I'd also rather see IE's download manager implement full Bit Torrent support.
  
  

  scobleizer wrote:

  If we did most of the above, would that be interesting to you?

  
  
  Yes.
  
  

  scobleizer wrote:

  If not, what would get you interested?

  
  
  I posted my suggestions in the wiki.
  
  

  LarryOsterman wrote:

  Manip2 wrote: I really want to know how you can ship a file-system after the fact. Really, can you imagine if NTFS had been shipped in Windows 2000 SP2.

  
  
  First off: NT's had a robust IFS model since NT 3.1.  It was designed into the original product.  So there's no technical issue with shipping a filesystem after the product.  I believe that NT 3.1 filesystems still run on XP (they might not, don't quote me on this one).
  
  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.
  

  
  
  So basically it is a database about your computer?
  

• 

  Shining Arcanine wrote:

  
  
  So basically it is a database about your computer?
  

  
  
  It's a database.  You can put stuff in it (metadata).  Typically the metadata has to do with things about the files on your hard disk. A perfect example of this is the metadata associated with music tracks.
  
  The metadata for your music tracks includes:
     Artist
     Title
     Length (in minutes)
     Album
     Record Label
     How much you liked the track
     Contributing Artists
     Back up singers
     Album art
     the location of the Music Video of the track
     keywords
     etc.
  
  The metadata for a Word document might include:
     Author
     Reviewer
     Title
     Synopsis
     Length (in pages or words)
     Keywords
     etc.
  
  WinFS is a storage engine that's used to keep track of all that information.  The thing that makes it cool is that it exposes that information through a single API, and that allows other applications to browse through the metadata for those documents, be they word documents or music titles.  Now think about what happens when the shell can now look up that data for all your music AND all your word documents using the same API.
  
  That's what WinFS is all about (from what I understand, I'm not on the WinFS team).
  
  Scoble could describe it better, since he's talked with the team.
  

• 

  Seems like yesterday that ObjectSpaces was defered to LongHorn - now what? Is it still in WinFS? Will it be released at all?
  
  thanks
  
  Chris
  

• 

  This is still gonna be a good OS. But why can't you release Longhorn Server and Longhorn client, at the same time?
  Avalon and Indigo should be in Windows Server 2003 and XP. I like playing all the latest  games, and I don't want my desktop taking up my GPU power. Making my performance go lower and have to buy more faster GPU's. I think other gamers will agree, they will not really like this OS. Besides even if you want to have that latest card. Your games are still gonna run faster and more reliable on XP.

• 

  Diego: the Dogme thing is good! I'd take it.
  
  Larry: I think that covers the waterfront pretty well. For more, search Channel 9 for "Sam Druker and WinFS" -- his videos cover quite a bit, albeit now they are outdated since WinFS won't be in the 2006 version of Longhorn.

• 

  scobleizer wrote:

  Eric Rudder: we don't allow makeup on Channel 9. That way we can separate the geeks who hang out indoors coding Longhorn from the guys who go out and play golf with clients.

  
  
  

  Robert: Have you ever thought about making taking the Dogme 95 "Vow of Chastity"?

  
  
  

• 

  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).
  

• 

  BOFH wrote:

  
  Okay, basically, nothing's really changed... if you go back far enough. Back during the Whistler beta, the roadmap was quite simple - Whistler, followed by Blackcomb. The specifications for Blackcomb were laid down, UI prototypes and concepts were created and demoed at the Financial Analysts meeting by Steve Guggenheimer, and Blackcomb was all set to become the next major client release of Windows.
  

  
  
  I can confirm this. Here is an email in my Inbox from Microsoft dated Tue, 27 Feb 2001 19:01:27 -0800
  
  

  Paul Richardson (WINDOWS) wrote:

  
  Thank you for the report.

  The WindowsXP development team is aware of this issue and there have
  been other reports of similar behavior. As such, this bug has been
  resolved as "duplicate". But at this time, only the most critical bugs -
  bugs that will stop the shipping and/or deployment of WindowsXP are
  being fixed. The master bug will remain active and be re-visited after
  the release of WindowsXP for further consideration/investigation.
  The problem you describe is currently not possible because the XXXX
  XXXXXXXX is not fully PnP (among other reasons).  When it is uninstalled,
  it requires a reboot before it can be re-installed due to some services
  not being able to shut down.  We don't allow components that require
  reboots on uninstall to be re-installed without rebooting first (for
  many, many good reasons).  Resolving this as a duplicate of the
  XXXXX-removal bug for Blackcomb, which has the XXXXX PnP bug as a
  duplicate.

  If you disagree with this course of action please send me mail
  explaining the reasons why the bug must be considered for the WindowsXP
  release and we will revisit the issue at that time and escalate
  accordingly.

  Thank you again for your efforts and support,
  Paul Richardson
  Windows Whistler Beta Team
  

  
  
  So ? What is your current estimate on timing for this bug report to be fixed ? 2001-2008 (Blackcomb) or 2001-2005 (Longhorn) ?
  Anyway - several years for a fix - this is cool
  

• 

  BOFH wrote:

  
  Since MS have been, officially, very quiet about DCE - even at the WinHEC and PDC events - some people still fail to understand that whilst Avalon is the "presentation layer", it isn't the rendering engine which Explorer Glass is built on. That function still comes down to DCE, which will not be backported to XP.
  

  
  
  Actually, I think you got some of the fine points of the Avalon graphics architecture wrong here.  Avalon does include the rendering and compositing engine.  The DWM is being built on parts of the Avalon platofrm.
  
  The main part here to keep in mind is the UCE -- Unitified Composition engine.  This is a evolution from what we were calling the DCE (Desktop Compostion Engine) and the ACE (Application Composition Engine) early on.  We basically looked at the problems we were solving to composite applications on the desktop and we looked at the problems we had to solve to composite controls inside the app and discovered (huge surprise..) that these situations were very similar.  So we merged these two parts together to create one unitified engine.
  
  An instance of the UCE runs as part of every Avalon application (doesn't matter on OS) and does the composition for the client area of that application.  This will allow any app developer to do transparencey and other cool composition effects inside of the window.  The output of this UCE gets passed desktop management system for dispaly.  When the DWM isn't running, this means that the content gets presented by DX or GDI (depending if HW accel is being used).  When the DWM is running this content gets passed to an instance of UCE running inside of the DWM process.
  
  The DWM process has an instance of the UCE that is special in that, when the DWM is running, it is the thing that finally takes the content and puts it on the screen via fulls screen DX.  It is essentially an Avalon application that takes all of the client areas for each application (GDI, DX and Avalon alike) and merges those together into the composited desktop.
  
  The basic architecture won't change with this announcement.  However, the DWM will only be shipped on Longhorn as it is impossible to reasonably retrofit the redirection capabilities necessary to make it work on XP and W2k3.  But *inside* the client area of an application the Avalon architecture remains essentially unchanged.
  
  There are more details in my blog here: http://www.eightypercent.net/Archive/2004/08/30.html#a208.
  
  Joe
  
  After-post mint:  I kept reading and it looks like you guys are way ahead of me and found our WinHEC slides.  Avalon will basically run as it always has inside the window.  The desktop composition stuff will be built on parts of Avalon and will run only on Longhorn.

• 

  JBeda wrote:

  BOFH wrote: Since MS have been, officially, very quiet about DCE - even at the WinHEC and PDC events - some people still fail to understand that whilst Avalon is the "presentation layer", it isn't the rendering engine which Explorer Glass is built on. That function still comes down to DCE, which will not be backported to XP.

  
  
  Actually, I think you got some of the fine points of the Avalon graphics architecture wrong here.  Avalon does include the rendering and compositing engine.  The DWM is being built on parts of the Avalon platofrm.
  
  

  
  
  Yes, I wasn't sure as to whether or not you'd still be including application-specific hardware acceleration, but I was sure you wouldn't attempt to port the DWM effects or the LDDM back to XP and Server 2k3, as it would pretty much negate the whole point of releasing longhorn at all.

• 

  I just find it hilarious how people are saying that LH is going down the tubes, JUST BECAUSE MS removed winFS from the inital release of LH which as many people on here stated, IS NOT, I repeat IS NOT a "File System", but rather a meta data storage system that interacts with the NTFS file system (which for all purposes is pretty da*ned good). First off for all of the linux zelots in here, quit your b*tchin, as long as MS continues this path of producing better quality products then before, linux will fail miserably as an end-user system just do to the fact that MS is established so well and has the ease of use factor (not to mention the 'purrrrrdy' factor as of LH). 
  
  Second off, I think LH will be a turning point for MS in the platform development market. Before they've delivered "OK" products, Windows XP, a bit better but now with longhorn on the horizon you can see massive changes in the way MS is running things. Making it easier for not only the end user, but also for the developer. So imo the loss of winFS in the inital release is realy no big deal, probably 3/4 of the end user market wouldnt even notice it in the first place.
  
  Well thats my two cents, keep up the great work guys!
  

• 

  crispybit wrote:

  I just find it hilarious how people are saying that LH is going down the tubes, JUST BECAUSE MS removed winFS from the inital release of LH which as many people on here stated, IS NOT, I repeat IS NOT a "File System", 
  ....
  

  
  
  Nobody told here that they are worried if this is FS or nope.
  Main issue is trust. Then Microsoft will anounce next time that they are going to build "next big thing" - nobody will trust them.
  If you are unable to maintain schedule - keep it private!
  
  Take a look on Apple. They keep all information about future private, but they produce cool products !
  I believe that there is no needs for Microsoft to anounce their plans up to 10 years ahead.
  Simply keep old (possibly a little bit modified  cover page wording from 1990 annual report "Our most important accomplishment during our fist 15 years has been to prepare ourself for the next 15"
  
  JFYI: 1990+15 = 2005

• 

  Trying to catch up on a bunch of WinFS stuff in this thread:
  
  WinFS is a metadata store for things are currently files, but is a primary store for things that are not usually currently files (contacts, mail, appointments, tasks, schedules, annotations, etc.).
  
  I won't make any definitive grandiose statements about what a filesystem is or isn't, but WinFS stores files, stores regular non-file data, and stores meta-data, as those terms are commonly understood. It responds to fopen/fwrite of path based names so in my book it's a file system.
  
  Generally, Larry's overview is decent--it just misses the non-file stuff that ends up in WinFS via your mail application, your scheduler, your event planner app, your list manager, etc.
  
  WinFS does take advantage of the NT file system driver structure to provide those services. We actually store the filestreams of file typed items as streams just like in NTFS (but with some extra stuff to handle transactions). We store non-file data just like SQL Server does (well, like most like SQL as of Yukon, although we have a couple of finely tuned advancements beyond Yukon's serialization formats).
  
  WinFS is based on SQL Server of course, and the SQL Server code is mostly native C++. SQL also provides a hosted CLR environment for managed programming in the store. WinFS client is implemented in two halves: as a set of enhancements to the store written in C++, C# and T/SQL and as a set of specialized objects that provide the basic CRUD operations via O-R mapping, exposes a model for transactions, query (opath), business logic, query notification, cursoring, Rules composition, sync adapter API's and so on. This part is almost completely written in C#, although some bits are actually generated C# in a data-driven way from XML.  
  
  The first part of that (CRUD) is the part that's similar to ObjectSpaces. We have not yet figured out what the change means to the ObjectSpaces plan and we'll have to work that out as we get settled into the new logistics.
  
  Those of you expressed anger, sadness, anxiousness and anticipation about WinFS: thanks. We are still working very hard on this project and it means a lot to know there are customers that want us to get it done and get it done right.
  
  Samuel Druker
  WinFS
  
  Edit: I think scobleizer already pointed here, but just in case
  
  https://weblogs.asp.net/jmazner/archive/2004/08/29/222493.aspx
  

• 

  Manip2: WinFS is a layer on top of NTFS, not a replacement. You aren't going to lose any data, it will just be a wonderful layer for developers and WinFS-aware applications (e.g. Windows Explorer, Outlook Express, and ISV apps).

• 

  BOFH: That was the most interesting and enlightening thread that I've read on Channel 9 since I started following discussions in these forums. I'm obviously going to have to pay strict attention to your replies in the future!
  
  On this whole subject I'd just like to cast my vote on what's happening and say that I'm very glad MS delayed everything to get XP SP2 ready, at last a response to the people who want MS to take the responsibility for protecting non-technical users. It's a shame that it has pushed the dates for Longhorn back but at least they've admitted that they can't finish it all in the time available and have made a decision about how to handle it. If this is the direction that MS are heading in these days then I, for one, would say this is A Good Thing.
  
  If what I've said reads as incredibly naive then please put me right but after years of everyone hating MS for, well, being basicaly bastards a lot of the time, this does feel like a change for the better.
  

• 

  Given how far along ObjectSpaces was/is(?), I wonder if there was any discussion about decoupling it from WinFS and releasing it along with Avalon/Indigo in XP: The empire strikes back? Maybe in a less ambitious form.
  

• 

  AT wrote:

  I believe that there is no needs for Microsoft to anounce their plans up to 10 years ahead.

  
  
  As a developer I wholeheartedly disagree.  Microsoft's new, open attitude is a great thing for me and helps me to do my job more effectively.  Ok, maybe I can't plan 10 years down the road but I can certainly plan 3-5 years.  Discussing features that will or won't make it to the final release, and keeping us updated, is really important to developers.  Keep up the good work guys!

• 

  JamesC wrote:

  
  
  As a developer I wholeheartedly disagree.  Microsoft's new, open attitude is a great thing for me and helps me to do my job more effectively.  Ok, maybe I can't plan 10 years down the road but I can certainly plan 3-5 years.  Discussing features that will or won't make it to the final release, and keeping us updated, is really important to developers.  Keep up the good work guys!

  
  
  3-5 years ? Can you tell me then your next paycheck will arrive ? Every two weeks ? Ohh ...
  This mean that company you are working for - need solution currently, today, already installed and working .... !
  
  I believe that focus on far future is flawed. I preffer more focus given on current Microsoft offerings.
  As developer - visit https://msdn.microsoft.com and take a look that you see  ?
  Instead of assisting you with current development problems - you see articles about product you will not be used in production for at least 1-1,5 years ! This is clearly an attempt to push you to buy this new product.
  Sure .. This will benefit you if you will read all thouse articles in advance.
  But for most of msnd.microsoft.com visitors - they need their projects to be done today, not in 2+ timeframe. So you are unable to benefit from thouse articles currently
  

• 

  Hello !
  
  I want to know exactly or aproximatly when is Windows Longhrn going to appear !  I think it will appear in 2005 but i wanna know exactly !  And what will be his minimun requirements, medium requirements, and high requirements !!
  
  e-mail me with the answer at: alex_xero@yahoo.com