As many of you may know, I tend to blog about things I encounter in my day-to-day work that I think might be of general interest. And for the past two years, even though I've run into things that were "blog-worthy", I couldn't write about them in public. And thus no blog posts.
But that's changed now that the //Build conference is over. I can finally talk about some of the things I've worked on over the past few years. Most of the things will come through more official channels: the "Building Windows 8" blog, the windows dev center, etc. But I do hope to write more about what I have done in the past and what I'm doing these days.
So what *have* I been doing for the past two years? After we shipped Windows 7, I moved from the Windows Audio team to a new team known as the "Runtime Experience" team. The Runtime Experience team is responsible for the architectural elements that make up the new "Windows Runtime" which is a part of the next version of Windows. My development manager, Martyn Lovell gave a great talk at the //Build conference about the runtime here.
My work has focused on developer tools to enable authoring windows runtime APIs and designing the metadata format used to represent the windows runtime APIs. It's a bit esoteric and geeky, but I've had a huge amount of fun working on this over the past two years.
Anyway, that's a very brief version of my job, and as I said, I hope to be able to write more often in the near future.
Good to have you back with us, and I'm sure you've got plenty of interesting WinRT discussions/insights to share.
Now I finally have an answer to that question you couldn't answer two years ago when I was roaming the hallways with Charles. :)
It sounds very cool, like the kind I of thing I would probably enjoy working on as well. I hope you'll have some stories to share.
Charles from C9?
Anyway not exactly dark, but certainly less populated...
(BTW: How far are you with that Station? :D )
Welcome back, Larry!
After a project has been secret for years, I find it takes a while to get used to it not being secret anymore.
As well as other people finally being able to see the fruits of your labour, it sure is nice, when explaining things to people, not having to fire up a VM just to take a screenshot that doesn't disclose unreleased features. :)
I hope some of the forthcoming WinRT information from the team will discuss how/whether you can use some of the new WinRT APIs from Desktop apps. Info on that has been a bit conflicting so far. Obviously parts of WinRT only make sense to Metro apps, but I think it'll be a shame if the Desktop world is completely cut-off from all of it, as some of it sounds useful.
(At least until when/if WinRT becomes viable for all kinds of apps, not just full-screen interactive suspendable sandboxed apps. But if there is a plan for that I'm sure it's something that is still under wraps. :) Out with one set of secrets, in with another!)
The windows runtime works from both desktop and metro, but some APIs are metro-only, some are desktop-only and some work in both places. It's up to the team that owns the APIs to decide which works where. The plan is that there will be documentation available about which API works in which environment.
Yay! Larry's back! I'm looking forward to the upcoming posts.
That would make this slide very misleading: davidburela.files.wordpress.com/.../clip_image0014.png
@Quppa: Most "boxology" slides are simplified. There are only 5 windows runtime APIs intended for desktop application (one intended for debuggers, another 4 for package deployment on machines with developer tools installed). It doesn't make sense to extend the "windows runtime" box under desktop applications for 5 APIs. The windows runtime is primarily intended for use by metro style applications, the fact that a very small subset of the windows runtime APIs also happen to work on the desktop doesn't change that.
Thank you for the reply, and point taken (and it seems that particular slide has other issues, too: dougseven.com/.../a-bad-picture-is-worth-a-thousand-long-discussions).
There was a lot of speculation about 'Direct UI' (arstechnica.com/.../2) - is that just the codename for the XAML layer that's used with WinRT? And is it at all related to the 'Direct UI' found in Windows Explorer and Windows Live?
I'm glad that WPF hasn't been thrown under the bus for desktop development, but at the same time I'm a bit disappointed that this new performant UI framework is restricted to Metro style applications. Perhaps I'm being short-sighted here, but I find it difficult to imagine using immersive apps outside the tablet/phone scenario.
There's been some ... discussion ... in various places about whether WinRT really is a peer of Win32 or not. Are you able to comment on this? To what extent does WinRT depend on Win32?
The Windows Runtime is built up of lots of APIs. Some (like the sensor APIs and the XML APIs) are relatively wrappers around existing APIs. Others (like the input APIs) were built from the bottom up. In all honesty, I'm not sure why it matters though. Metro style applications will use the Windows Runtime APIs, and they may also use existing Win32 APIs (for instance if you're writing a game, you'll probably use DirectX).
question ... I'm not a developer but wondering if desktop apps get the benefits of sandboxing because of WinRT? Or is that a feature only metro apps can take advantage of?
@miro: Desktop apps are desktop apps and don't run in an appcontainer. Only metro style apps can run in an appcontainer.
Can metro-apps communicate through some kind of IPC? (like pipes,...)
Welcome back Larry !