Why all the C/C++ interest all of a sudden?

We have VB.net and C#.   All the C developers I know use C#(and like more) for managed apps.  Why not leave C and C++ for device drivers or some other performance situations.  Who in the right mind would write C++ for a Metro App?    Are there alot of MFC programmers who came off the boat and cannot learn C#?   I don't get Microsofts interest here.

 Faster apps perhaps. With the way Windows 8 will be doing things, we'll be able to get the same eye candy from the .NET languages with the performance of C++. Best of both worlds. Although I'll agree doing C# is considerably easier and faster to develop with than C/C++. 

IMHO: it's driven by multiple MS Windows Teams, the following blog explains it very well:

http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars

Quote:
 "... WinDiv, dissatisfied with DevDiv,..."

My personal conclusion: WinDiv created something like an 'Anti-CLR', named Windows Runtime (WinRT), but IMHO it's an architectural disaster! For example:
They extracted a confusing subset of the Win32 and COM API, see MSDN::
http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fapps%2Fbr205757.aspx 

and now they call this 'reinventing windows'!

@DevTomSch: I think it ought to be clear at this point that the ultimate intention is to kill off Win32 entirely, but there were clearly a bunch of old API's that were still going to be needed for the time being either because they're difficult to effectively refactor into the OO WinRT world or because they're less widely used and therefore can wait till the next revision to be given the full treatment.

Any notion that this wasn't all part of a bigger plan long before the first previews of Win8 is clearly wrong. Quite why they felt they couldn't simply say something about there being a story for C# and VB developers is beyond me. I can only assume it was felt that any attempt to clarify matters might have ended up with them saying that .NET and Silverlight were (effectively) now legacy technologies, which would then have required them to start talking about WinRT earlier than planned.

@AndyC: They probably wanted folk to think the worst so whatever came out wouldn't seem half as bad.

It would be nice for someone who thinks they will be using C++ to write Metro Apps to chime in and tell me what advantage you buy.   Dont tell me portability or you cannot learn C#.   I think you guys are hitting the nail on the head that .NET is legacy.  This story is still fuzzy right now.

some more hints, the CLR was called URT (Universal Runtime) inside WinDiv.

some more funny hints.

CLR was called COR or 'Component Object Runtime', as the next version of COM.

.NET was called  NGWS or 'Next Generation Windows Services'.

https://www.microsoft.com/Presspass/press/2000/jun00/forumumbrellapr.mspx

.NET has these goals:

Improved User Experience Puts People in Control
Ease of Use/Simplicity
Internet Standards
Business Integration and Opportunity

.NET has such a component

.NET User Experience. A new set of technologies for building next-generation user experiences, including the new Universal Canvas XML-based compound information architecture, natural user interface, ......

and .NET Passport has a role in the picture,

So Windows 8 looks like a 'reimplementation' of all these vision of NGWS, 10 years after, right ?

Gates RULEZ!

C++ ROCKS </ET>

C++ has improved a lot with the new standard and all, it's quite competitive to C# in general productivity and probably has a much larger developer base.

3 hours ago,TomboRombo wrote

It would be nice for someone who thinks they will be using C++ to write Metro Apps to chime in and tell me what advantage you buy.   Dont tell me portability or you cannot learn C#.   I think you guys are hitting the nail on the head that .NET is legacy.  This story is still fuzzy right now.

Here's one... as for the advantages, let's just say that C++ is the stick shift of computer programming

Seriously, it's a matter of personal preference and of being able to use the right tool for the job. Or at least one of the right tools for the job. It's also a matter of welcoming as many developers as possible to the new platform, letting them use their weapon of choice.

Might not work as intended, but I think it beats the "Objective C only, please" kind of policy hands down.

The right tool for the job....C++ is very much the only game in town when you need extremely high performance apps.  Think anything in the algorithm world like imaging or real time analytics where you have to wring every ounce of performance out of your app.  C# and Java simply don't cut it in these areas and anyone trying to push that those languages are even close to the performance of C++ are full of it.  Well written C++ is several times faster than the same code written in C#.  Sure there are fringe cases where C# can approach C++ speed but my bet is those are cases where C# is calling in to native code that is doing most of the work.  But pure C# vs. pure C++?  No contest.  And no, I am not trying to start a flame war.  I use C++ and C#, making value judgments on which tool is right for a specific job. You don't drive screws with a hammer do you?  I have seen too many projects fail or suffer because someone chose tool A simply because they or their team knew tool A instead of choosing the appropriate tool B.

That isn't to say your whole app has to be written in C++....C# can be the presentation layer or the db access layer, that totally makes sense.  But you would have to be nuts to say write an FFT routine in C#.  Microsoft cannot cut off C++ because it needs it as well as it's ISVs in order to deliver the high performance business apps that their customers need.

I don't know these languages, but how "close" is Objective C to C/C++? Maybe they're trying to sway Apple devs?

I would say C# is closer to C++ than Obj-C is to C++. Obj-C uses a very different object model based off of Smalltalk. Even on a syntactical level it isn't similar.

It seems to me that the perf hit I get with C# is mostly related to layout in WPF/SL.  It sounded like the Xaml layer for C++ was native C++ code.  Is that true?  Is it faster?

The Xaml and presentation stack of Silverlight is NATIVE, and the WinRT Xaml component is directly ported from Silverlight's agcore.dll.

Because C/C++ is used for big real apps. Almost none of the programs you use on a day-to-day basis are written in anything other than C/C++:

The NT Kernel: Written in C
All of Office (apart from Exchange): Written in C++
The Explorer shell: Written in C++
All of your device drivers: Written in C or C++
Wireshark: Written in C++
Visual Studio: Written in C++ (some of the GUI is managed C++)
Open Office: Written in C++
Any popular game that you care to mention: Written in C++
Skype: Written in C++

You get the drift. C# is great for mini-apps and apps for internal use in your company, sure, but when it comes to apps being sold for real money, C/C++ is where the industry is, and it's hardly surprising that Microsoft takes steps to make them happy.