The following is the full source code for a component that adds 2:
public sealed class AddTwo {
public int Add (int a, int b)
{
return a + b;
}
public async IAsyncOperation SubAsync (int a, int b)
{
return a - await (CountEveryBitByHand (b));
}
}
Sorry for being an idiot here, but.. does this example make any sense to anyone else? There's a method that adds two numbers, but the async operation is SubAsync which subtracts something passed through CountEveryBitByHand from a... passed through something called await? Is this obvious to other people? Does he mean that any sealed class automatically becomes a component, so the AddTwo part is just the Add method? What does "a component that adds 2" mean anyway?
I suspect the second method is just an example of how you could make an asynchronous operation that performs a subtracting of two numbers, after a method (CountEveryBitByHand) is completed.
To keep it simple they should have left out the second method.
CountEveryBitByHand() is a function which returns a promise. (I don't know if that's what they call it in C# 5.)
The await keyword is a new one in C# 5 which halts execution until the promise is fulfilled. Then execution is resumed from that point, and the expression can be evaluated and the function returns.
It's similar to how inlineCallbacks in Twisted work, if you're familiar with those.
Miguel is a pretty l33t developer, so he glosses over a lot of the details.
I suspect that code is contained in a class library project. Aka, generates a DLL. So no, not all sealed classes will be components.
The second method is there to illustrate what asynchronous programming will look like in C# 5. Native support for async is THE big feature in C# 5. The "await" allows you to call slow blocking code without a thorny nest of callbacks. There's some magic behind await. You can find out more on Google. Miguel could've definitely left out the SubAsync method in this example for clarity.
A component that adds 2 means a DLL that exposes the methods Add and SubAsync. In WinRT, you can code libraries in C# and use them in C++. Or Javascript.
Aha, that almost makes sense. You're saying "add 2" might mean a component that exposes two methods. Not sure what exactly he is demonstrating there, actually. I mean, here's a DLL written in C that exposes the same two methods (although not asynchronous):
int Add(int a, int b) { return a + b; }
int Sub(int a, int b) { return a - CountEveryBitByHand(b); }
So, I guess the example is just to show the async stuff, really.
When you use C# and VB, you are using the full .NET
framework. But they have chosen to expose a smaller
subset of the API to developers to push the new vision
for Windows 8.
For me, this is a really interesting point that this article doesn't fully get. When you use WinRT you might be using the C# compiler, CLR runtime and .NET string & collection classes, but there are huge sections of the .NET BCL that now look like a lame duck. WinRT is the new way to do XML, JSON, HTTP, networking, security, globalisation, threading, printing... (more here: http://msdn.microsoft.com/en-us/library/windows/apps/br21137...)
You can still use the full .NET class library when doing ASP.NET, but who wants to use different JSON classes for App development vs. Web development? Won't the WinRT version gradually become the preferred way of doing JSON in both environments, with the .NET BCL existing to fill in the server side only gaps?
This is a really interesting question. I did some quick skimming over the docs there and even where there is conceptual overlap, the BCL wins in terms of feature breadth. It would be challenging to replace it, I think.
Not just for the user - calling asynchronous tasks using the new C# or VB keywords is so mind-bogglingly easy that you'll just have no excuse not to do it when writing apps.
Even the use cases that are not covered by the two keywords, like fetching a whole bunch of stuff together or issuing a lot of requests and having the data trickle in as they are completed one by one are handled easily with the Task API, to the point where you have WhenAny and WhenAll methods and you just do "await Task.WhenAll(tasks)".
I agree. This API will be a paradigm change for Microsoft. I particularly liked Miguel's explanation as well. In fact, it's the only one I found that really explained it in programmer's terms. Now, how soon will there be a Mono implementation fo this I wonder?
Aye, as someone who didn't have many expectations (though I didn't expect Windows 8 to be a failure either, I'm not one to rage about changing the sacred desktop look), throughout the keynote and this video they managed to pleasantly surprise me many times.
The design aside (which is an entire topic on its own), some of the functionality decisions like contracts just make you wonder why the sodding hell didn't we have these sooner. I mean there's the half-baked drag and drop handler than no one actually bothers to implement even when it makes absolute sense to do so, and that's it. Being able to pull things out of a web service from the file picker, on the other hand, just makes me go "I want this yesterday."
"You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application"
I'm curious to know, how will the review application be able to catch your use of the private API through reflection? It seems like a pretty hard problem that could be a big security risk if done incorrectly.
I don't know, but it just _might_ be time for Microsoft to do jail-style security, in which you can't actually reflect from libraries you have no permission to.
What is "then ()"? Have they created their own wacky fork of Javascript? Javascript already handles asynchronous programming (feel free to argue that is doesn't do it "right" or even "well"), so why extend the language?
I'm assuming they only chose to use this pattern for the purpose of keeping function/method signatures as uniform across the languages as possible? I can't see another advantage to this in JS. Seems like all it's doing is wrapping the call to the actual async operation within the 'then' function, and then probably using the callback as the last argument or storing it somewhere where it will be accessible to the async operation right before it returns.
From what I can tell it's just a convention in their APIs for binding continuations. You do some WinRT asynchronous call and pass a func to the then method to run when it completes. Nothing more than a onFinished event.
No changes to async programming at all, events and continuations as always.
I'm not a DirectX developer, but it looks to me like I've got huge swaths of DirectSound directly available from C#. I can check something specific, if you'd like.
I'm developing an app for surveillance that talks to multiple IP cameras and microphones. We made the unfortunate choice of C# early on.
- no normal RTSP support. Ok, I used libav (working hard to wrap it, cause it's a well written C library, but not trivial to use from C#)
- I get h264 frames that I need to look at before decoding. No way to give compressed h264 frames to WPF to decode. (So I use libav again). SilverLight actually does have MediaStreamSource -- but this is not a SilverLight app.
- Ok, so let's try to use the hardware decoder when it's there. libav supports it, yay! What about WPF? Well, no. You have to use Direct3D (?) to get a surface to draw on. With no way to do this from C# (Interop fails badly according to a DirectShow+Direct3D MVP I consulted). I give up, and use libav's software decoder.
- Ok, I have a bitmap, I want to blit it quickly to the screen - WTF? The only way to do it is use a Shared Memory section (interop again) to create a bitmapsource; then update the underlying memory.
- Except memory runs out after about 20 seconds (~400 frames) of .Invalidate() calls. WTF? Turns out it's a known bug introduced in v4 (wasn't there in v3.5). No fix yet. Just call GC.Collect() after every invalidate. Yay for "automatic" garbage collection!
- Ok, so now we have got a reasonable video. What about sound? Everyone with experience I know says "use NSound" (which is interop again). I opt for interopping with winmm, which I have experience from the C++ side.
- Now, to wrap it all together, I need a millisecond-precision timer. Sorry, no go in .net; Winmm's "timeBeginPeriod" to the rescue! but .net's Dispatcher still triggers my code every 15ms. WTF? I would be happier with a 100us timer, which windows doesn't even provide, but I can't get less than 15000us!
I'm so sorry we chose .NET; it seems to cater well to CRUD type applications, but it is so inadequate for everything I tried to do with it, that it's not even funny.
Probably not. I need frame-by-frame timing control. These APIs don't seem to deliver anything previous APIs didn't - just make it a little easier to use.
I looked at it, but it didn't appear that libvlc gave me the level of control I needed (frame accurate seeking and reporting, access to framebuffers, stuff that low-level). Perhaps I didn't look closely enough...
Just to clarify: my "it appears to be there" was in reference to the WinRT-powered DX11.1 in Windows 8. Your experience sounds exactly like why I wouldn't be doing anything vaguely low-level in C# in Windows 7 or earlier.
And you're comment is exactly why I wouldn't do it in Windows 8 either.
There hasn't been a single time when the answer to some deficiency was not "Well, this version of Windows/.NET is cr*p, but the next one is going to be perfect for every need".
I didn't choose to go with C# for this project - someone else did. Being the low-level guru, I was called in to fix all the deficiencies.
Really, .NET has been out for 10 years now, WPF for 5. There is no excuse for this abysmal level of support, and until I see Win8 actually working properly with sample code that addresses stuff such as I mentioned above, I won't consider it.
Sorry. That sounds like something meant for C++. Most of this sounds like pretty key stuff like the timer. Didn't anyone do a basic proof of concept first to flush this stuff out? Just curious.
Yes, they did a proof of concept using the MediaElement, with windows driven playing -- that actually works. And they assumed that fine timing control, different codecs, frame accuracy etc would be available if needed.
I agree it's meant for C++ on Windows (if it is meant for Windows at all - the 15ms timer precision thing runs so deep it bites in many places you wouldn't expect).
But Microsoft and MS fanboys keep touting that "C# is all you need to get things done" - that has never been the case, and I expect it not to be the case with WinRT either.
It's amazing to see just how much Apple is driving the industry. Microsoft is making an app store, completely rethought their UI and programming model for mobile devices...
Is it a joke and I'm not getting it?