In prior times, let's use Vista as an example, we were introduced with the DWM (Desktop Window Manager) which had cool new features like Aero glass. These features are baked into Win32 though, which means you have to P/Invoke to use them from .NET. The .NET team would have to write wrappers around the new Win32 features to make them available in .NET, but because of time constraints, that stuff never made it into .NET API's. WinRT removes this problem by allowing the Win32 API to be directly available through WinRT, so you can just directly access it. This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

Now here's the flipside, and the problem I see. WinRT right now is not really accessible to .NET, its accessible to Metro apps. And Metro apps are far limited in the API's they have compared to .NET. WinRT only has a subset of API's from .NET, like it doesn't include things like WPF, Silverlight, or WinForms because those don't make sense in WinRT. But the API's are severely restricted to API's that only make sense to Metro style apps.

I think the limitations and exclusions in WinRT are what make .NET developers feel like .NET is going out the window, and I agree with the concern. WinRT apps actually can only use specific API's, otherwise your app cannot be included in the App Store, and thus cannot be available to Windows 8 consumers.

I'm going to stop there. I hope this clears up some confusion. I like the idea of improving the Win32 layer with WinRT, but I think restricting the API's and favouring Metro style apps only is a very bad decision. Personally I am a fan of compatibility (Windows XP, Windows Vista, Windows 7) and am an avid supporter of the Desktop. I personally wouldn't use WinRT for any serious applications, that's my take.

16 minutes ago, DeadX07 wrote

This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

Which is terrific. What I do not understand is the shift to native over managed. I thought the thinking on performance had been that the next generation of hardware would solve that problem.

And I do not follow why the JITer and GC the .NET framework cannot smply be improved to address performance problems.  I am impressed with how quickly the shell namespace extension I wrote recently in C++ starts up. The preview handler I wrote starts instantly. But why would a .NET version have to be slower? Can there be prestarted .NET processes, which somehow are able to latch onto a set of preloaded .NET assemblies at process start ( if assembly loading is the cause of slow starting .NET apps. )?

2 hours ago, SteveRichter wrote

I am interested to read what Anders thinks about WinRT and the deemphasis of .NET.

De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

WinRT supports .NET, HTML5 and C/C++. This has been the case since the modern Windows programming model was announced at BUILD 2011.

So, your base assumption is incorrect, thus this post is irrelevant. That said, Anders works on the C# and VB languages, both of which can be used to build modern Windows 8 style apps. You can also build shared WinRT components in C# or VB that can be used from JavaScript and C++.

Where's this confusion stemming from? Is it because we (I, especially) have been promoting C++? I've already addressed that aspect several times.... C++ evangelism went mostly dark during the .NET Everywhere years and my goal has been to push native into the forefront (where it belongs), bringing how and when we talk about C++ up to par with .NET content on Channel 9.

WinRT doesn't pick favorites... If you're a .NET developer, then you're all set. If you're an HTML5 developer, then you're all set. If you're a C/C++ programmer, then you're all set. This can't be made more clear. 

C

9 minutes ago, DeadX07 wrote

Managed code will never be as fast as close to the metal native. Managed code lives because of abstraction concepts, and abstraction equals cost.

right. But next years tick/tock of the processor will give us hundreds of millions of more instructions per second, erasing whatever gap there is with the native app. And of course there is many core which is predicted to give apps multiples of CPU resources.  I understand hand held devices have power constraints. But is it predicted that 5 years from now a WinRT native stack will be needed compared to a device that runs mostly managed apps?

I think there is just a "misunderstanding" of what WinRT is, and I think there is a lot of tension from .NET developers because they think Metro will replace WPF, and eventually deprecate .NET. I don't think either of those will be true, not just for compatibility reasons, the desktop is not going away.

I think the big push for mobile/tablets and bringing them together on the desktop in Windows 8 has a lot of people nervous as well. It's a very bold move and many don't know what to feel about it yet.

I think right now one thing Microsoft could do is help by, (and without promoting Metro/WinRT or doing anything related to advertising/marketing) is to better explain:

1) What is WinRT
2) Why does it currently only support Metro style apps if its a "successor" to Win32
3) Why does it only expose a subset of .NET API's and "govern" which ones can be used in WinRT apps (this makes developers feel limited, and they don't like that)
4) What is the future of WPF/Desktop (and including WinForms even, people still use it)

If I'm wrong on any of these points I apologize and would love clarification. These are based on my own understanding of WinRT/Metro and concerns I hear from other developers.

@SteveRichter It doesn't really matter how powerful hardware is. Managed code runs on native code. It doesn't exist without it, and no matter what type of device it is or how powerful the hardware, performance and reliability of the runtime/platform/operating system/device should always be the #1 priority.

That being said, .Net morphing into WinRT with better performance because it is planned in is great.  You still use C# as you normally do just calling into windows is more direct.  When they get WinRT to cover what the .Net libraries do we will be better off. 

I dont mind using C/C++ on projects where .Net is not available.   For Charles to say they are bringing back C++ back to where it belongs with C# and VB is just a strange comment.  All of us who started with C/C++ enjoy C# development because it is just plain better and more enjoyable to program.   If I need to write a device driver I am glad the C compiler is still supported but we are comparing apples to oranges.

28 minutes ago, Charles wrote

*snip*

De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

Just saying I would like to hear from Anders.

28 minutes ago, Charles wrote

Where's this confusion stemming from?

Partly for me it is that I would have expected a Windows 8 OS to be a lot more .NET centric. I think I even remember a Charles C9 video from years ago where he asks the windows server guys why .NET is not a part of server core, the implication being .NET is going to become more and more a part of windows. The message I was receiving from years of C9 videos was that .NET and multi core were it and naturally assumed Wiin32 and .NET would morph into 1 on future versions of the OS.

Really not complaining.  I understand plans change. But I am a bit sceptical of the native guys saying in 2012 that we need every tick of the CPU clock we can get to run a responsive, power friendly app.

1 hour ago, Charles wrote

*snip*

Where's this confusion stemming from? Is it because we (I, especially) have been promoting C++?

*snip*

It seems that way.  However, if there were more Charles to go around then I'm sure the technologies would be carried equally on C9 at roughly the same time.  Resources are resources.  Regulars here know C9 has limited resources.  But the general web sees the collective output from Microsoft, and that includes C9, and it screams native, native, native, oh and html/javascript.

It doesn't help to not be seeing the .NET technology stack folks talking about .NET and the new boundaries to take advantage of.  Maybe they can't until RTM.  RTM has been hit recently.  Let's see if that changes.

1 hour ago, Charles wrote

*snip*

I've already addressed that aspect several times.... C++ evangelism went mostly dark during the .NET Everywhere years and my goal has been to push native into the forefront (where it belongs), bringing how and when we talk about C++ up to par with .NET content on Channel 9. *snip*

Herb Sutter espousing micro savings on data center scales adds to it.  Listening to things on this scale is almost like the IBM mainframe days.  I hear .. if you write .NET code you are costing us to have to build 14 more nuclear generators and killing mother earth.  I'm sure that isn't the main intent.  It isn't a warm and fuzzy.  I'm not sure why I haven't understood.  From a pure "as-is" efficiency argument? ... maybe.  But data centers are not appliances.  <strike>The software running on them has to constantly evolve.  Developer productivity needs to trump saving kittens.</strike>

1 hour ago, DeadX07 wrote

I don't think either of those will be true, not just for compatibility reasons, the desktop is not going away.

Why do you think Microsoft won't push WinRT for Desktop app development too?

3 hours ago, DeadX07 wrote

In prior times, let's use Vista as an example, we were introduced with the DWM (Desktop Window Manager) which had cool new features like Aero glass. These features are baked into Win32 though, which means you have to P/Invoke to use them from .NET. The .NET team would have to write wrappers around the new Win32 features to make them available in .NET, but because of time constraints, that stuff never made it into .NET API's. WinRT removes this problem by allowing the Win32 API to be directly available through WinRT, so you can just directly access it. This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

Don't you still have to wrap your Win32 API in WinRT objects before you can take advantage of Projection? And MS doesn't have a monopoly on wrapping Win32 APIs in .Net code. They're just usually the one's expected to do it.

Further, BUILD 2012 will be chalk full of sessions that make all of this even clearer... Do tune in.

Now, with respect to the comment about C++ developers preferring C#, well, that's simply not true. You use the right tool for the job at hand. Period. For WinRT, a great use case for C/C++ is that of building high performance shared WinRT components (that both .NET and HTML5 applications can call into). Also, you can imagine taking an existing native application (where portable libraries are used in addition to platform specific, and proprietary, UI layers (a la Obj-C and Cocoa Touch on iOS...) and porting them to Win8. Also, if you write games and want to do so with DX, then use C++. Further, if you want to mix XAML and DX in an app (like Bing does, for example), you use C++. It's not apples to oranges. It's using the right tool for the job at hand. Finally, if C++ is your preferred language, then you just use it along with XAML for UI to build modern apps on Win8...

With WinRT, you can use multiple tools simultaneously to get the job done and in a way that maximizes user experience...

If you are attending BUILD 2012, then you will learn all that you need to clear up any confusion here. If you can't attend, then you can watch all the sessions right here on C9 on-demand.

In terms of more Charles to balance native and .NET content, I've done various interviews that cover .NET 4.5, from GC to JIT to Fx installation. I assume you've watched those pieces?

C

Further, .NET is a significant piece in Windows. Think of Media Center UI, PowerShell admin scripts (and, like Windows 7, the way wizards do their thing....).

C

@brian.shapiro I have no doubt that WinRT will eventually be available to desktop applications. Simply put, there is a fear in a lot of .NET developers minds that WinRT will replace WPF, which is simply not the case unless Metro is allowed to run on the desktop as well, which currently it cannot. WinRT makes specific assumptions, for example, that only one Metro application is open at a time, which would not be suitable in the desktop environment. Things can change, but since it is just rolling out as V1, not anytime soon.

@Charles Agreed. .NET is not suitable for OS development. Also, you have done PLENTY of .NET coverage... countless interviews with Anders, Bart De Smet, Erik Meijer and more... so I don't understand why it's an issue. .NET lives because of native and they should be greatful that C++ is evolving into a even more modern language.

There are too many new areas to cover right now.. C++ 11, Windows 8, Visual Studio 2012, .NET 4.5, C#5, VB, the list goes on. Poor Charles cannot cover them all at once! Unless maybe you have a few clones laying around.

-Josh

7 hours ago, Charles wrote

De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

C

I think this thinking emerged from mid-2011, with Bob Muglia's 'stragegy has shifted and Silverlight (also WPF) is dead' and Steve Sinofsky's 'HTML5 and Javascript is the way to develop on Windows 8' messages,  the 'C++ Renaissance' also contributes in someway.

articles like these appears and went to Slashdot.

http://www.i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html
http://www.i-programmer.info/professional-programmer/i-programmer/2830-was-net-all-a-mistake.html
http://developers.slashdot.org/story/11/08/03/2027207/Wasnobr-wbrnobrNET-All-a-Mistake

IMHO its the result of the secrecy policy of Sinofsky about Windows 8. Giving a little bit of message once a while and keep mouth shut when people are in doubt and having questions, its very frustrating and kills trusts and confidence.

http://www.hanselminutes.com/329/understanding-winrt-and-windows-8-for-net-programmers

Scott's confused about what 'WinRT' is. Is it a new .NET? A new runtime? Is .NET dead? He's totally confused so he talks to Immo Landwerth who sets him straight with complete context from Win32 to COM to .NET and beyond.

for .NET vs. C++ discussions, you may want to watch this Java vs. C++ (vs Javascript) talk by Cameron Purdy

http://www.infoq.com/presentations/Keynote-Lessons-Java-CPlusPlus-History-Cloud

9 hours ago, DeadX07 wrote

Managed code will never be as fast as close to the metal native. Managed code lives because of abstraction concepts, and abstraction equals cost.

ok so managed can only be 98% - and 99% of the time that last 2% is not even a blip on the radar!

honestly i think that for *most* apps managed is plenty fast unless the app is poorly written or is extreemly crtitical - like some core OS code.

most of the time when folks think it's slow etc... it's from bad code or not understanding how it really works.

9 hours ago, Charles wrote

*snip*

De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

WinRT supports .NET, HTML5 and C/C++. This has been the case since the modern Windows programming model was announced at BUILD 2011.

So, your base assumption is incorrect, thus this post is irrelevant. That said, Anders works on the C# and VB languages, both of which can be used to build modern Windows 8 style apps. You can also build shared WinRT components in C# or VB that can be used from JavaScript and C++.

Where's this confusion stemming from? Is it because we (I, especially) have been promoting C++? I've already addressed that aspect several times.... C++ evangelism went mostly dark during the .NET Everywhere years and my goal has been to push native into the forefront (where it belongs), bringing how and when we talk about C++ up to par with .NET content on Channel 9.

WinRT doesn't pick favorites... If you're a .NET developer, then you're all set. If you're an HTML5 developer, then you're all set. If you're a C/C++ programmer, then you're all set. This can't be made more clear. 

C

I have not seen anything from Mr. Anders in ages here on C9  and the coverage on win 8 has been focused more often on the "shiny new bits" that most of the time say nothing about .Net

that is why many of us feel like .net has been "demoted" and Anders has "gone dark"  heck i wonder if he is leaving or retiering ?

possibly a job somewhere else ?

http://channel9.msdn.com/Events/Ch9Live/Channel-9-Live-at-BUILD/C9L201

7 hours ago, DCMonkey wrote

*snip*

Don't you still have to wrap your Win32 API in WinRT objects before you can take advantage of Projection?

True, but the biggest problem .NET developers have faced is not performance, it's that there is a massive delay between new technologies becoming available in Windows and suitable quality Managed Wrappers being in place (the Ribbon being a classic example, but there are plenty of others). And developing your own wrappers is both time consuming and potentially problematic if "official" libraries come out in future that wrap things differently. C++ developers have suffered similarly, but it's considerably easier to just call C style APIs there.

WinRT brings a standard method for exposing new APIs in Windows that can easily be consumed from whichever platform suits the developer. Long term this has the option of makingn .NET (and potentially JS) much more of a first-class development platform than it has ever been before.

I am not talking about 2D drawing, I am talking about WPF basic controls.

I hope there is something about that. And also the processing of collapsed elements. I think it is faster to have elements collapsed and re-enable instead of remove them and add them when I want to modify the list. But, my previous experience, those collapsed elements still cost quite a lot of calculations. 

A lot of performance issues are with presentation layer instead of raw calculation speed.

for .NET vs. C++ discussions, you may want to watch this Java vs. C++ (vs Javascript) talk by Cameron Purdy

http://www.infoq.com/presentations/Keynote-Lessons-Java-CPlusPlus-History-Cloud

Felix9,  thanks for the link.  I have not seen that before but it nicely summarizes plus and minuses of both. 

I just dont agree with the last slide.   He basically says Rich Client is the future.  To me,  that has always been here it is just becoming popular.   That is what Silverlight was already doing .  Smart client with webservices.

Now, with respect to the comment about C++ developers preferring C#, well, that's simply not true. You use the right tool for the job at hand. Period.

Well I will just disagree the first sentence and agree with the second.   I use both everyday and I tend to enjoy the C# environment more.  If C# was made into a compiled language without .NET (no GC etc) I would use it for everything.

C

15 hours ago, felix9 wrote

*snip*

I think this thinking emerged from mid-2011, with Bob Muglia's 'stragegy has shifted and Silverlight (also WPF) is dead' and Steve Sinofsky's 'HTML5 and Javascript is the way to develop on Windows 8' messages,  the 'C++ Renaissance' also contributes in someway.

Nobody has said that HTML5 is "preferred"... It's the newest way to build Windows apps, yes, - and it's frankly quite amazing that you can build powerful modern style client applications in HTML5 on Windows 8 - outside of a browser... Pretty awesome, if you ask me. That said, it's one of three main ways to get to the job done. It's time to get past the "what about .NET?" stuff and accept that in reality .NET is as first class as every other programming model that targets modern style apps on Windows 8.

Can we move along?

C

17 hours ago, felix9 wrote

for WinRT and .NET discussions, maybe this episode of Hanselminutes is a good one

http://www.hanselminutes.com/329/understanding-winrt-and-windows-8-for-net-programmers

*snip*

for .NET vs. C++ discussions, you may want to watch this Java vs. C++ (vs Javascript) talk by Cameron Purdy

http://www.infoq.com/presentations/Keynote-Lessons-Java-CPlusPlus-History-Cloud

Apparently, Hanselman needs to, too (just kidding, Scott!)

C

1 hour ago, Charles wrote

@felix9: Well, that's more the result of speculation than reality.

*snip*

Nobody has said that HTML5 is "preferred"... 

<snip>

Can we move along?

C

Two comments:

First of all, I also don't get why people, especially developers, with common sense could be confused about the status of .NET. In particular it appears that .NET will have more easy access to OS components in Windows 8. Maybe it's because some people still think back to the role of "managed code" in the Longhorn days.

That said, I seem to remember a comment when Windows 8 was first demoed publicly by Sinofsky and, Julie Larsen, where there was a remark that made it seem like HTML 5 development had suddenly been raised to a preferred method of developing apps for Windows 8. Of course that's nonsense and anyone with common sense should be able to deduce what was meant. It does show how easily confused people get about future directions.

I'm sure Felix can track down the comment - although it's just for historical curioisity at this point.

10 hours ago, TexasToast wrote

If C# was made into a compiled language without .NET (no GC etc) I would use it for everything.

The GC isn't just an implementation detail of .NET. It's a critical design feature. Without it, you'd have to explicitly new and delete every object, introducing the sudden possibility of double-free vulnerabilities and memory leaks, i.e. removing any semblance of memory safety across the entire language, undoing what is arguably C#'s biggest achievement.

1 hour ago, wsdotnet wrote

@evildictaitor: I don't think compiling c# to native would take away the some of the parts of the GC. I have been using mono touch for some time and as I understand it mono compiles the c# down to native code IOS code before it gets loaded on the device. So i think it would be possible to do this.

It is of course perfectly possible to compile C# to machine code and run it without a JIT. It is not possible to run it without a GC.

19 minutes ago, evildictait​or wrote

*snip*

It is of course perfectly possible to compile C# to machine code and run it without a JIT. It is not possible to run it without a GC.

Nitpicking, Bartok does have a option "nullgc" which means no collector
The only problem is your memory wont be reclaimed, but if you dont allocate much its OK I think.

BUT i find it very weird that MS are using HTML for the MAJORITY of the Bing/Live/Xbox apps (looking at 15+ MS made apps all of which are HTML and a very very small fraction is XAML/Dx) ... it's like theres an internal memo to build everything in HTML,

i seriously don't know why at least the Video/Music apps wernt XAML/Dx, to me that would sound like the perfect technologies to showcase a video/music app ...

currently the Music/Video apps are unimpressive apps that are frankly embarassing and MS could do so much better (ala XBOX dashboard) ...

3 hours ago, exoteric wrote

That said, I seem to remember a comment when Windows 8 was first demoed publicly by Sinofsky and, Julie Larsen, where there was a remark that made it seem like HTML 5 development had suddenly been raised to a preferred method of developing apps for Windows 8. Of course that's nonsense and anyone with common sense should be able to deduce what was meant. It does show how easily confused people get about future directions.

I'm sure Felix can track down the comment - although it's just for historical curioisity at this point.

Hmm... no, believe it or not, it didnt sounds like the HTML5 is the 'preferred' way, instead, it sounded like HTML5 is the 'only' way for the new UI ! everything else is still supported but just for the old UI !

https://allthingsd.com/20110601/up-next-at-d9-microsoft-windows-president-steven-sinofsky-live-at-d9/
https://allthingsd.com/20110620/windows-for-the-app-age-microsofts-steven-sinofskys-full-d9-interview-video/
https://allthingsd.com/20110601/exclusive-making-sense-of-what-we-just-learned-about-windows-8/
https://www.microsoft.com/en-us/news/features/2011/jun11/06-01corpnews.aspx

Discussions here:
http://channel9.msdn.com/Forums/Coffeehouse/What-platforms-should-I-invest-my-time-in
http://channel9.msdn.com/Forums/Coffeehouse/On-the-plus-side
http://channel9.msdn.com/Forums/Coffeehouse/OK-Microsoft-has-gone-crazy

People knew it can't be true, but its still 'poor developer communications and PR'
http://www.theregister.co.uk/2011/06/06/windows_tablets_without_silverlight_dot_net/

To be fair, Charles clarified this the next day on Channel9 https://channel9.msdn.com/posts/A-quick-look-at-Windows-8#c634425734130000000
but this was almost the ONLY outspoken MS employee for three months, in a comment of a post ! Peter Brown may be another one, everyone else was saying "None of us at Microsoft can say anything until //build/ in September." Ouch.

Even MaryJo Foley wanted to stop the FUD
http://www.zdnet.com/blog/microsoft/microsoft-needs-to-tell-windows-8-developers-now-about-jupiter-and-silverlight/9608

But people still had this impression in August.
http://channel9.msdn.com/Forums/Coffeehouse/Steven-Sinofsky-addressed-developer-frustration-and-confusing-about-HTML5-vs-Silverlight-strategy/6bd0147f989f4052bb9c9f4200204d04
http://blogs.gartner.com/david_m_smith/2011/08/17/microsoft-buldinging-suspense-but-letting-confusion-fester/

All in all, this ridiculous thinking might be a result of 'speculation', but stupid PR from Microsoft definetively set it off and helped a lot to spread it.

Scott Hanselman was obviously joking in that podcast I mentioned, but the joke itself reflects the situation of reality, isn't it ?

OK. That's all for today's history lessons, lets move along.

10 hours ago, felix9 wrote

*snip*

Nitpicking, Bartok does have a option "nullgc" which means no collector
The only problem is your memory wont be reclaimed, but if you dont allocate much its OK I think.

Even with C/C++ in embedded projects we do not dynamically allocate memory.   We try to statically get everything setup on initialization.  This is much safer and allows software to run without leaks and memory concerns.    We need to run 5 9's for reliability and cannot take this risk.  I was hoping that the Micro .net framework would take this approach with turning off the GC as an option.

1 day ago, Charles wrote

*snip*

In terms of more Charles to balance native and .NET content, I've done various interviews that cover .NET 4.5, from GC to JIT to Fx installation. I assume you've watched those pieces?

Yes.  But this did cause me to rethink what is it that is missing.  Maybe it isn't more Charles type content.  Its up to the elbows in code, design, and whys content.  As an example

Windows API reference for Metro style apps

Let's delve into these new APIs.  How about the Windows.Foundation.HResult.  Can that be used anywhere we would have PInvoked into Win32 to get the result or is it only applicable for WinRT api triggered results?  The Windows.UI.Xaml.Controls looks prime for some need to know information from the experts.  Maybe there are some gotchas or different defaults from wpf/silverlight past experiences.

Alas ... "[This documentation is preliminary and is subject to change.]".  No need to read it and catalog an invalid something in a brain cell.  Maybe it is simply too early to even have a conversation.  Let's hope not because they want apps out in the app store sooner than later I've been hearing.

Note: C9 does not have a WinRT or Win+RT tag.  Also in reviewing the .NET various tags I know there was a lot more content that I had seen than what was coming up under those tags.  If it helps anyone else Windows+8 was an additional tag that reveals more content.  It isn't in the tags listing that I saw but there is content tagged with it.

1 day ago, Charles wrote

*snip*

If you're an HTML5 developer, then you're all set.

If only this were true =(

Unfortunately the learning curve of HTML5 Windows 8 apps is too great, I don't think it will find the adoption Microsoft wanted. And we have first hand experience with this, building an internal Windows 8 app for Microsoft, done in HTML5/WinJS....NOT a fun experience. Our next Windows 8 app is going to be built in Xaml/WinRT, so hopefully a much better experience =)

C

I've had two guys from the Visual Studio team wanting to chat with me too, but they never connected.

Doing web for 12 years myself, the HTML5/WinJS is simply a way-too-high-learning-curve-nightmare to use. My main focus was front-end, and my team lead was on the back end and he knows 10x more than I do, and he was struggling to hack things to get them working.

I've been making stuff for Microsoft for 12 years(we're a vendor), and I've never disliked many projects in those 12 years...this was one of the first ones I'd categorize as "horrible", and that includes working on lots of SharePoint stuff =)

C

Problem with Windows 8 development is lack of resources...mainly MVPs. Half the times when I needed answers to something, the #1 search result was my post on MSDN...#saddeveloperpanda

Problem is I think MVPs are getting the cold shoulder from Microsoft on getting answers themselves.

4 hours ago, Harlequin wrote

Problem with Windows 8 development is lack of resources...mainly MVPs. Half the times when I needed answers to something, the #1 search result was my post on MSDN...#saddeveloperpanda

C

Damn near every page in the "Dev Center - Metro style apps" site is completely useless. I spent time for each of my issues when we were building out WIndows 8 HTML5 app to look at the Dev Center first...then Google second, which brings up nothing, then the only resource is the Metro forums.

There is absolutely zero evangelism for Windows 8 development.

The thing is that all those articles and tutorials elsewhere are fine for getting to grips with the basics, but when you want to dive deeper and read up on some type you found, MSDN is useless.

Take ISupportIncrementalLoading, for instance. I wanted to find out how to make a gridview load more items as the user reaches the end, but all the forum posts and tutorials on the matter seemed confusing. I could gather that the ISupportIncrementalLoading.LoadMoreItemsAsync() method was key, so I decided to read up on it. All the MSDN documentation tells me is what the interface's member's are (which Visual Studio could already tell me) and that it "Specifies a calling contract for collection views that support incremental loading." That's too general and too vague. The LoadMoreItemsAsync() documentation simply says "Initializes incremental loading from the view." No information on the weird IAsyncOperation<LoadMoreItemsResult> return value. No information on how to implement this thing, exactly. Just very basic descriptions of the types and members that IntelliSense already gives me.

Same with implementing drag and drop: the XAML editor told me about UIElement.AllowDrop, but the MSDN page simply says "Gets or sets a value that determines whether this UIElement can be a drop target for purposes of drag-and-drop operations." So, great, I kind of gathered that. So what do I do when it's set to true? I don't know, because the MSDN page doesn't bother to tell me about it. I just sort of assume there's a Drop event, and so there is, but that documentation also doesn't tell me a damned thing about wat to do when the event is fired. How do I figure out what has been dropped onto the UIElement? Can I tell wether it has been dragged there by mouse or by finger? Does it fire once for every item that has been dropped or is there a collection of all simultaneously dropped items that I can look at somewhere? MSDN sure won't tell me. I have to click on through to the DragEventHandler Delegate, for which the documentation is also completely barebones, and then onto the DragEventArgs page. Here, I find a Data property. Success! I can probably figure out what has been dropped in there. Oh wait, the documentation is again useless. All I can tell from it is that the Data property is of the weird DataPackage type. And what do you know, a Remarks section! But wait, it only supports text, RTF, HTML, Bitmap and StorageItems by default? Why can't I just get the object that was bound to whatever has been dragged from there? Maybe I can, because the documentation tells me that "It also has methods to support custom data formats". So how do those work? MSDN won't bother to tell me. It stops just short of giving me the finger. In the end, I just didn't bother with AllowDrop and the DataPackage and just rolled my own implementation using the ManipulationStarted, ManipulationDelta and ManipulationCompleted events. For which, incidentally, the WPF documentation has a whole section about what to do in this event and how to use the eventargs, where to go for more information about manipulations and a pointer to a walkthrough for touch enabled applications. The WinRT documentation has basic intellisense data and a single "Using manipulation events" link hidden in the See Also section.

The MSDN documentation sucks. It sucks hard. The most useful sources of information on Metro app development for me have been the MSDN forums, google, and just poking around in intellisense. Apart from a few how to articles there is nothing on MSDN that you can't already find with intellisense, and that's not nearly enough.

C

I'm extending a thank you from the doc team to all of you who commented on the doc state (very useful feedback!).

Do stay tuned. It will get much better

C

Even if Bas couldn't find details on MSDN, which is the case most of the time I'm sure for all of us, there is usually a blog post by someone awesome where they were doing exactly what you were trying to do. Right now, with Windows 8, the only way to figure out complex things, wether it be back-end or front-end, you need to hit the forums, where sometimes you get an answer in 2 hours, sometimes 2 days. Not the way to go when we have deadlines in real life.

2 days ago, Charles wrote

@Bas: I've been on email with the doc team. They are very responsive and helpful.

I'm extending a thank you from the doc team to all of you who commented on the doc state (very useful feedback!).

Do stay tuned. It will get much better

C

Allow me to send a thank you back to the team; at least the pages I mentioned in that post are now much more fleshed out, with much more elaboration in the remarks section and a few code examples. This is much better indeed.

C