My (very preliminary) Win8 + WinRT impression!
-
Super Lloyd wrote:
and it feels like normal C++
:~ That looks like C++/CLI, not normal C++, although apparently we'll be able to write WinRT code in standard C++ as well.
Nemanja Trifunovic wrote:
although apparently we'll be able to write WinRT code in standard C++ as well.
Provided you are fine with making all those COM calls yourself. I'd think it's far easier to use a syntax that is already familiar. I reckon they figured not many use it for managed code, so they may as well use the same parsers and stuff for native code :-)
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Nemanja Trifunovic wrote:
although apparently we'll be able to write WinRT code in standard C++ as well.
Provided you are fine with making all those COM calls yourself. I'd think it's far easier to use a syntax that is already familiar. I reckon they figured not many use it for managed code, so they may as well use the same parsers and stuff for native code :-)
Regards, Nish
My technology blog: voidnish.wordpress.com
Nishant Sivakumar wrote:
I'd think it's far easier to use a syntax that I am already familiar.
FTFY! Not many people use c++/cli (last time I counted it was only 1 person using C++/CLI) ):) COM programmers still prefer to do it the COM way which feels more C++.
-
Nishant Sivakumar wrote:
I'd think it's far easier to use a syntax that I am already familiar.
FTFY! Not many people use c++/cli (last time I counted it was only 1 person using C++/CLI) ):) COM programmers still prefer to do it the COM way which feels more C++.
Rama Krishna Vavilala wrote:
COM programmers still prefer to do it the COM way which feels more C++.
Well eventually it's a choice. People can still use standard C++/COM or use C++/CX and cut down development time big time.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Rama Krishna Vavilala wrote:
COM programmers still prefer to do it the COM way which feels more C++.
Well eventually it's a choice. People can still use standard C++/COM or use C++/CX and cut down development time big time.
Regards, Nish
My technology blog: voidnish.wordpress.com
Nishant Sivakumar wrote:
C++/CX and cut down development time big time.
The problem with the new syntax is that people have to learn it. I still get confused with sometimes with the ^ syntax. Whereas in standard COM you do not have to do anything special. You get smart pointers, you know how to call a method and with smart types )_bstr_t,_variant_t things gets even more simple. The only thing available in the new syntax is . instead of ->. That may cut development time slightly as you have to type only 1 character instead of 2. Apart from that I do not see any other benefit.
-
Before you get all excited C++/Xaml is WinRT only. Means you can't use it for normal desktop apps or for WPF/SL. And WinRT apps will always be fullscreen / immersive. You can have 2+ apps side-by-side though but together they will still be fulscreen.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Nishant Sivakumar wrote:
You can have 2+ apps side-by-side though but together they will still be fulscreen.
How does that work if my full-screen app needs all 1024x768 (or whatever) pixels to display itself?
Vark111 wrote:
How does that work if my full-screen app needs all 1024x768 (or whatever) pixels to display itself?
Xaml usage recommends not specifying pixels and instead using relative sizes/alignments. That way the UI auto-resizes as required.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Vark111 wrote:
How does that work if my full-screen app needs all 1024x768 (or whatever) pixels to display itself?
Xaml usage recommends not specifying pixels and instead using relative sizes/alignments. That way the UI auto-resizes as required.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Super Lloyd wrote:
and it feels like normal C++
:~ That looks like C++/CLI, not normal C++, although apparently we'll be able to write WinRT code in standard C++ as well.
Nemanja Trifunovic wrote:
apparently we'll be able to write WinRT code in standard C++ as well
I'm not sure where you've read this. AFAIK, you have to conform to the CX format to work with WinRT - you will still be able to use libraries such as boost, but you have to use this syntax for actual WinRT libraries if you want to actually have your code "Activatable".
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
I think I will finally able to write C++ app! I love how they improved COM and it feels like normal C++ and you can write UI in XAML and use databinding!! I love the performance! But.. I hate this fullscreen mode! I have a 26" screen for god sake, why a window with just, say, a button and a text box need 26"? Why?
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
I want to make my app work across all win8 form factors and I'm fine with touch-first/metro as a paradigm. But I'm concerned how my app will work on desktop environments where desktop apps are the norm. Can someone see my metro app on the screen next to multiple desktop apps? What I really fear is that I will have to write 2 separate apps, one for metro and one for desktop. It seems I won't be able to combine the formats into one executable that auto selects (or even offers the user an option) to run as metro or desktop. How does task manager really work? I understand that non-visible metro apps are suspended. What about desktop apps? Do they get suspended when metro apps are running? Are there 2 different task managers? One for metro, one for desktop? Is win8 a seamless experience from touchpad to desktop? It seems desktop apps on the touchpad will be second class... as they should be. But it seems metro will be second class on my desktop... which shouldn't be the case. Maybe this is why Hyper-v is avail on win8 client. I can run Win8 as a vm on my Win8 pc. I'll run metro stuff in the vm and desktop stuff on the host.
modified on Friday, September 16, 2011 9:35 AM
-
OK, well you have to remember that WinRT is meant to be for what are called "immersive" applications in MS speak. More importantly, the surface has to be entirely WinRT - it does not support GDI, so airspace issues are avoided altogether by requiring these applications to be full screen. This also avoids performance penalties and conforms to one of the underlying principals, that Metro apps are full screen - consistent with the behaviour of Metro on WP7. If you want to create normal style desktop applications, you are going to have to fall back to the standard windows tooling.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Pete O'Hanlon wrote:
by requiring these applications to be full screen
I wonder how this will impact tasks that require one to look at two application at the same time. Will this ever allow this new approach to be the only? How is this gonna be in multi monitor environments? I still need to see this for myself, but I see problems of a full screen only on some scenarios. A phone and a tablet? ok, but on a desktop? Maybe not always.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
Before you get all excited C++/Xaml is WinRT only. Means you can't use it for normal desktop apps or for WPF/SL. And WinRT apps will always be fullscreen / immersive. You can have 2+ apps side-by-side though but together they will still be fulscreen.
Regards, Nish
My technology blog: voidnish.wordpress.com
Nishant Sivakumar wrote:
And WinRT apps will always be fullscreen
Huh, missed that somehow in all the hoopla. I actually *like* that idea, non maximized windows drive me batty when I see them on other people's pc's while they are trying to work in some kind of tiny window.
There is no failure only feedback
-
Nishant Sivakumar wrote:
C++/CX and cut down development time big time.
The problem with the new syntax is that people have to learn it. I still get confused with sometimes with the ^ syntax. Whereas in standard COM you do not have to do anything special. You get smart pointers, you know how to call a method and with smart types )_bstr_t,_variant_t things gets even more simple. The only thing available in the new syntax is . instead of ->. That may cut development time slightly as you have to type only 1 character instead of 2. Apart from that I do not see any other benefit.
The new ^ reminds me of pointers in Pascal. Ahh, the old days. C# is way more fun.
-
Pete O'Hanlon wrote:
by requiring these applications to be full screen
I wonder how this will impact tasks that require one to look at two application at the same time. Will this ever allow this new approach to be the only? How is this gonna be in multi monitor environments? I still need to see this for myself, but I see problems of a full screen only on some scenarios. A phone and a tablet? ok, but on a desktop? Maybe not always.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
Metro applications can be docked one next to the other, one application docked to the right and the other docked to the left, so you can see both at the same time.
-
Nemanja Trifunovic wrote:
apparently we'll be able to write WinRT code in standard C++ as well
I'm not sure where you've read this. AFAIK, you have to conform to the CX format to work with WinRT - you will still be able to use libraries such as boost, but you have to use this syntax for actual WinRT libraries if you want to actually have your code "Activatable".
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
I was about to ask whether this means that MS decided to block out all cross-platform development, but decided to read up on that myself. ;) It turned out my (then uninformed) conclusion was valid after all, but your assertion that you cannot use C++ with WinRT is wrong. Check out for instance the screenshot and explanations in this article at readwriteweb.com. Seems like WinRT takes a similar place in Metro development as MFC used to take in Win32 desktop app development. And yes you can use C++ and even C to call the WinRT API. With that pic in mind I now finally understand what the MS marketing people meant by 'native' HTML - in this contect what they meant was the next best term to 'proprietary' and 'unportable', really; Metro offers developers a standard tool (HTML) to address an unportable, proprietary API (WinRT). Maybe it's just me not being a native english speaker, but I have some trouble associating the word 'native' with its intended (by MS) meaning ... :doh: All this makes me wonder what MS is thinking: in a world where the internet and open software development thrives, they close all the doors on cross platform development! Really? :confused: