Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WinRT demystified

tirania.org

Post reply on HN
Print view View original

31–40 of 48 posts

Re: WinRT demystified

#31

Post by IvoDankolov »

josteink wrote: post #11

Completely unrelated, but if the article didn't overwhelm you, the linked video session really is worth checking out. http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004 It shows just how much attention to detail Microsoft has put into the UX design of Metro and Windows 8. Can't wait to see the finished product.

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

Re: WinRT demystified

#32

Post by IvoDankolov »

batina wrote: post #2

Great explanation. Can't wait to finish downloading Windows 8 to start playing with it. Asynchronous API that will really make a difference for the end user, right? There won't be any more waiting for UI to unfreeze :)

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

Re: WinRT demystified

#33

Post by davidpadbury »

joeshaw wrote: post #19
krig wrote: post #16

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 subtr…

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.

(I don't know if that's what they call it in C# 5.)

Tasks - http://msdn.microsoft.com/en-us/library/system.threading.tas....

Re: WinRT demystified

#34

Post by pcj »

beagle3 wrote: post #22
gecko wrote: post #14

Earlier quoted context omitted.

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

Yeah, that doesn't fun at all. Just curious though, would these new API's [http://msdn.microsoft.com/en-us/library/windows/apps/windows...] address your scenario?

Re: WinRT demystified

#35

Post by rwolf »

kevingadd wrote: post #29
rwolf wrote: post #27

and Javascript uses promises and "then ()". 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?

It's a method with a signature like this: promise.then(callback) so: var p = doSomethingAsync(); p.then(function () { alert("hello"); })

I saw all of those extra spaces around "then" in the article and assumed the worst. Thanks for clearing that up for me!

Re: WinRT demystified

#36

Post by gecko »

beagle3 wrote: post #22
gecko wrote: post #14

Earlier quoted context omitted.

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

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.

Re: WinRT demystified

#37

Post by kenjackson »

beagle3 wrote: post #22
gecko wrote: post #14

Earlier quoted context omitted.

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

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.

Re: WinRT demystified

#39

Post by chucknthem »

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

Re: WinRT demystified

#40

Post by jbk »

beagle3 wrote: post #22
gecko wrote: post #14

Earlier quoted context omitted.

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

Use libVLC.Net :D

You get correct RTSP support, h264 decoding, hardware acceleration for decoding, DirectSound audio output and resampling.

Post reply on HN