Thank you very much Retesh. Brent and I worked really hard to make it happen.
I use "Epsilon" which is an EMACS clone made by Lugaru. I learned the original EMACS (which was a full screen editor for the DecSystem 20 at CMU) back in college and Epsilon is an excellent clone of it (it's dramatically faster than GNU Emacs).
@Charles: I had a blast, so much fun.
Oh and I want to be clear and not take the credit (the video makes it sound like I did more than I actually did): The problem I talked about at 4:30 or so was solved almost entirely by the media folks, I was just tangentially involved in the solution. I really messed up in the video.
@LordKain: In all honesty, without the language projections, the windows runtime is not really that fun to use. There are so many aspect of winrt that are simplified by the language projection - as a simple example, try programming a winrt app without using await/promises/ppl.
The strength of the language projections is that using the language projection takes what is nominally a fairly complicated set of constructs and simplifies them dramatically.
Looking forward, DVR is set.
Jan 11, 2012 at 5:15 PM
@Brice Richard:There was a fair amount of controversy about that "nobody understands" statement. But it's true - Back in the early 1990s, Dave Cutler was able to understand how every part of the system worked, but that's simply not true any more. I seriously doubt that there is ANY general purpose operating system in widespread use where a single person can understand how the entire system works.
There are people who know everything about how the filesystems and I/O subsystem work (and a lot about how memory management and the kernel scheduler works), but I seriously doubt they understand deeply how the display driver infrastructure works with the internals of GDI, User and DWM.
It's simply to big for one person to comprehend.
This is why have extensive internal documentation about the interactions between the various subsystems. Of course the quality and accuracy of that documentation varies from component to component but in general, it's good enough. And of course there are area experts that are well known within the Windows team - you've met several of them here on C9 (Arun Kishan and Landy Wang come to mind immediately).
@Sean:There were also other changes - all the notification area icons got new graphics - they went from multicolored and vaguely 3d to monochrome and flat as well.
Aug 12, 2009 at 11:07 PM
"In regards to managed. I was not proposing streaming bit in .net. More a bcl wrapper for config and metadata - start, stop, connect, status, change defaults, change endpoints, etc. The lower level will still handle the streaming. There has to be some managed story for this going forward. "
I don't know how you do start/stop without streaming - start/stop is intimately associated with streaming. But there might be an opportunity for managed wrappers for some of the other parts of the audio infrastructure, who knows what might end up being developed in the future.
androidi: One critical thing to consider - Windows tends to be developed for the noob. My quintessential example is my wife's riding instructor who is a stereotypical computer user. She ends up calling us when the sound stops working when she tries playing back DVDs (it's an issue with the sound drivers but I can't explain that to her).
Whenever I think about sound features, I try to think about how this stuff would work for her. Whatever we do has to be discoverable and usable for someone with little technical expertise. It also needs to solve a particular customer scenario.
I like staceyw's scenario above for that reason - he's describes a clean scenario where he's trying to accomplish something that he can't implement using our current system without a great deal of difficulty AND his scenario is something that I could easily imagine customers encountering. That scenario IS something that we might be able to address in a future version of Windows, Frank's already added it to the very long list of potential features (some of those potential features have been on the list for decades so there obviously are no guarantees about any particular feature being implemented).
Aug 12, 2009 at 7:09 PM
Androidi: A large part of the reason for those cards being so expensive is that the market for them is so small. Because the market is small, the price is high. Creative has some decent MIDI devices for between $50 and $100 though.
It's possible that if more apps used MIDI there would be a bigger market for MIDI hardware but the reality is that for most applications PCM audio meets their needs.
Aug 12, 2009 at 3:28 PM
Stacey, you're describing a system which would confound the vast majority of users adding a huge amount of complexity for unclear benefits.
Windows has always taken the attitude that application authors get to choose if they want to allow the user to specify a particular input or output device or if the application just wants to use the system defaults (of which there can only be one of course). At a minimum, it radically simplifies the programming model that app developers need to consider.
w.r.t. managed code, there honestly isn't a way to implement isochronous rendering of either audio OR video in managed code given the current state of the CLR. The basic problem is that the GC can come in at any time and freeze all the managed code in the application for 200+ MS at a time - this delay is troublesome for audio rendering and deadly for video rendering.