After a couple of days of watching video's I think I get it now. To be honest if
WinRT is managed or not doesn't matter. They created a COM interface for C++ people to use but added a lot of the CLI type syntax to deal with the new WinRT code.
It sure seems like the wrong choice for C++ guys, but thats me being stubborn. What I am now trying to figure out is how with HWNDs, HDC's and lots of old code can we integrate that onto a WinRT Canvas? Window? Whatever they call it. Also are numbers passed back via Object version of int? or an actual int? And... String handling. When you use devices they use lots of fixed char arrays to send text back and forth. Even SQL DB's have fixed field lengths. How do we interchange the String Object data with the fixed char arrays and vise versa.
To be quite honest it seems like a LOT of waste just to add cooler interface widgets, but thats just me being stubborn.
Funny how all the hater comments above have not apologised to Herb for flying off the handle without knowing the full story. It seems that one can (if they so please) code in standard iso c++ with no frilly extensions to the language! - Why doesnt everyone who took the time to comment here reply back knowing what they now know?
Why? Because we all heard this story before. WHY does MS choose to shove everyone into slower managed code?
SLOWER as stated by the developer from the DirectShow group who stated its as much as 2x slower. Slower just from a common sense perspective, an INT does not need to be converted to string all day long and does not need to be an OBJECT. The time wasted to allocate, manage memory and garbage collect is overhead that has made Visual Studio 10 fat slow and unsuable on embeded PC's.
C++ was not created to be managed. It was a comprimise between using Assmebly and C, on the low end and Java, VB,.NET or C# on the FAT slow end.
C++ people were hopeful for some new standardized interface tools that could be used to pretty up a C++ presentation. What we got was, fat code and accept the new managed C++ order.
From this new managed direction a C++ coder might as well program Android with Java or go to Objective C++. YES, MS does find itself in a pickle doesnt it?
Programmers see hardware and software choices springing up and Windows 8 is a year away. In that years time Droidx86 will be on version 3 or 4 and Windows 8 will be on version 1 and who knows where Mac will be. LOL..
What kind of advantage does Windows 8 give the C++ guy really? Managed code? Thats an advantage? Heck Java has been managed for quite some time and the performance has always been mediocre. That slow start up with .NET application as it loads its 100 or so DLL's or whacky single threaded UI in winforms/WPF is why people don't like to be managed.
Here is MY windows 8 MS suggestion..
1) DROP this managed C++ into the trash where it belongs.
2) Give us a function that we call to load a XAML interface file.
3) In that XAML load give us a call back that execute the necessary interface hooks (sounds like windows 3.1 doesnt it)
4) Give us a post message/send message way to fill these controls.
Lastly most importantly LEAVE C++ alone to be faster and best at delivering time senstive information. We dont want to be managed.. We want to be as close to the metal as we can be. We can manage our own threads and memory and create out own objects, thank you very much..
In the managed code world if I have 6 YUV HD DirectX surfaces and multiple DirectShow callbacks which feed my assembly language interpreters before I display them in realtime how would it fair when compared to C++?
These surfaces also interact with hardware callbacks for outputing. The display of these surfaces need to be realtime as well.
The interface, buttons/bars/combo boxes etc., does not need to be high performance.
It would fantastic to get ease of creating a modern XAML front end with all its glitz and glamor to work with this kind of C++ high performance multi-threaded back half without effecting the realtime performance of the C++ code wouldn't it?
In PDC 2009 the Microsoft DirectShow persenter said that managed code is more than 2x as slow as C++. So you can only conclude that WinRT and all its glamour will be not be for high performance bits and there is not a good way of making stylish front ends without rolling your own. (which I think is sad)