topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday April 18, 2024, 3:40 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Windows 8 - DirectUI, WinRT, .NET and c++ - Two worlds meet again  (Read 14947 times)

JoTo

  • Super Honorary
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 236
    • View Profile
    • Donate to Member
Hi DCs,

today i stumbled upon this very interesting article (and the informationw was new to me as well). So i'd thought i'll share for those that aren't up-to-date windows gurus (as i am not too).

In short:

First it is a nice (and even for lamers like me very understandable) wrap up of the history of
WinAPI, .NET and development under windows.

Secondly it gives some insight about the reasons under the hood for all the rumour around Windows-Development in the last decade and some internals how and why MS did what they did.

Thirdly it gives some interesting news from "slipped out" code snippets and informations from MS about the new APIs in Windows 8 named DirectUI and WinRT that should bring the UI Design under Windows to a "modern way of layout" using vector based approach (formerly WPF - Windows Presentation Foundation). It also brings all the rumour that Windows 8 will ONLY use HTML5 and Javascript as the main developer platform to an end.

Early this month, Microsoft dropped something of a bombshell on Windows developers: the new Windows 8 touch-friendly immersive style would use a developer platform not based on .NET, which Microsoft has been championing for the past decade. Instead, it would use HTML5 and JavaScript. Since then, the company has refrained from making any further comment on the issue. In particular, the question that has many Windows developers particularly concerned—how can I make use of my existing skills and experience when developing these new applications?—remains unanswered; the company plans to reveal nothing until its BUILD conference in September.

But the situation probably won't be as grim as many developers fear. Early milestone builds of Windows 8 have leaked onto the Internet, and considerable effort has been put into figuring out how they work. Though officially tight-lipped, snippets of information have escaped Redmond's walls. So far, it appears that Windows 8 development doesn't just look not bad—there are signs that it will actually resolve many long-standing annoyances with writing Windows software. If Microsoft can pull off everything it's hoping to achieve with the platform, Windows 8 will be as important and radical a release as Windows Longhorn was going to be.

Windows 8 will ship with a pair of runtimes; a new .NET runtime (currently version stamped 4.5), and a native code C++ runtime (technically, COM, or a derivative thereof), named WinRT. There will be a new native user interface library, DirectUI, that builds on top of the native Direct2D and DirectWrite APIs that were introduced with Windows 7. A new version of Silverlight, apparently codenamed Jupiter, will run on top of DirectUI. WinRT and DirectUI will both be directly accessible from .NET through built-in wrappers.

WinRT provides a clean and modern API for many of the things that Win32 does presently. It will be, in many ways, a new, modern Win32. The API is designed to be easy to use from "modern" C++ (in contrast to the 25 year old, heavily C-biased design of Win32); it will also map cleanly onto .NET concepts. In Windows 8, it's unlikely that WinRT will cover everything Win32 can do—Win32 is just so expansive that modernizing it is an enormous undertaking—but I'm told that this is the ultimate, long-term objective. And WinRT is becoming more and more extensive with each new build that leaks from Redmond.

In long terms:

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

Hope the (a bit lengthy) article is as interesting to read for you as it was for me.

Greetings
JoTo

PS:
A funny remark i read in a comment about this article in a mailing list was:
"I never believed that HTML5 and JS will be the ONLY developer platform for Windows 8. I don't think the next version of Microsoft-Office will be written in Javascript!" :) :) :)

Renegade

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 13,288
  • Tell me something you don't know...
    • View Profile
    • Renegade Minds
    • Donate to Member
Microsoft is notoriously bad at getting their corporate communications mixed up and sending the wrong message. I never worried about them dropping everything except HTML5 and JavaScript, but they really did drop the ball there, yet again. Still, you'd think that people would be smart enough to figure that out. Nope. Sigh...
Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker

worstje

  • Honorary Member
  • Joined in 2009
  • **
  • Posts: 588
  • The Gent with the White Hat
    • View Profile
    • Donate to Member
I can't say I'm cheering for the new developer platforms MS is pooping out this time around. I've got experience with WPF, and it is a horribly over-engineered piece of bloat. It can do some nice things, but even .NET v4 on Windows 7 has so many basic issues that doing what you want with it is never an actual option. I cannot count the amount of bugs I have worked around so far, assuming I was able to do so. My other grudges is that it, and every new OS version, just mess up accepted interface guidelines so designers can invent their own wonderous new thingy majiggies on top of existing controls. Even when I do my best to have the controls mimic the Windows ones, it looks fake and behaves subtly different. What is the point of having visual styles and themes anymore?

Win32 is not at all a pretty API, and yes, it shows its age and can use some improvements. However, it is FULL of fixed bugs, stability and is the most efficient thing there will ever be for application development. They need to stop trying to throw it away, since they've already shown that the .NET framework, and WPF in particular, have more holes, bugs and regressions compared to Win32 in it than they can fix in the next 10 years.

I don't like HTML5 and JavaScript either, but that is more-so due to the browsers than the theoretical technology itself. :)

[/the-old-days-were-so-much-better-modus]

mahesh2k

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 1,426
    • View Profile
    • Donate to Member
Here is my view, desktop version of OS and tablet version of OS will differ. Tablet version of OS is likely to have small footprint on disk with HTML5 and JS. But desktop version on which developers are heavily relying for graphic apps, media center and game development or other development will continue to be with the same core. Sure, MS wants to make things simple for tablet folks but that doesn't mean they'll rewrite core in HTML5 and JS and abandon all previous apps and projects creating huge gap for backward compatibility. Besides that if the core is purely based on browser (like chromeos) then all .NET and other desktop projects are trashed, that makes it more than 80% of windows revenue loss, more security issues with simple flawed OS design. Not sure if i get the picture clearly here. I think this announcement applies to tablet/pad based version of windows. In any case one bad move from windows is going to benefit linux.

Eóin

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,401
    • View Profile
    • Donate to Member
Whooo C++ whoooo!

rxantos

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 116
    • View Profile
    • Donate to Member
I wonder if by combining C++ with .NET they mean that all code will be managed code. AKA: not real machine code, but a layer over it.  While most applications do not need speed, there are some that do.

The win32 api might be old. But so is the unix api. Both have the benefit of being time tested and relieved of many unexpected features (aka. bugs). They also have the benefit that many developers know how to work with them.