Evolution in Data Integration From EII to Big Data
Approaches to integrating data are changing with emergence of cloud computing.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
WinRT: An Object Orientated Replacement for Win32
Posted by Jonathan Allen on Sep 13, 2011
WinRT isn’t another abstraction layer; it resides directly on top of the kernel just like the Win32 API. This marks the first major break in the core of Windows since Win32 was introduced in 1993 with Windows NT. WinRT represents a new application execution environment with semantics that are very different than Win32.
Unlike Win32, which was designed with C in mind, the WinRT APIs are written in C++ and designed from the beginning to be object oriented. Consistency, ease of use, and performance are key aspects of the new runtime API. Every object in the WinRT API supports reflection so that even dynamic languages such as JavaScript can use them efficiently. Along with this comes a unified object model, a rarity for C++ based libraries.
Side note: The Win32 API has not been removed and older applications using the traditional application execution environment will continue to work as expected.
C++ Development
User interfaces in C++ will be written primarily in XAML. This libraries for working with XAML have all been ported to C++ and are compiled to native x86. Metro applications written with XAML and C++ do not run on top of .NET, they get compiled directly to x86 just like any other Visual C++ application.
Calling methods on UI controls is just like calling methods on any other object in C++. At the machine code level one pushes the this pointer onto the stack and then invokes a function via a v-table. This allows for the best possible performance even on low power devices.
Libraries used by modern C++ applications such as Boost are supported.
Overlapping Windows No Longer Exist
Dialog boxes, a core concept from previous versions of Windows, does not exist in WinRT. The performance cost and usability concerns are simply no longer justifiable to Microsoft. Applications that wish to use this pattern will have to develop other ways to express things such as message boxes.
Another library that didn’t make it into WinRT is GDI. If an application is going to use the Metro interface it needs to do so from top to bottom, it appears that mixing Metro and classic user interfaces is not possible.
PlayTo Contract
Another contract that is being exposed is PlayTo. This allows applications to send media files such as audio and video to a charm. The charm will then allow the user to choose which application they want to use to view the file. Presumably these aren’t just physical files, but rather any form of media that can be expressed as a data stream.
C#/VB: The end of P/Invoke
Calling native functions from .NET usually involves building up structures and manipulating pointers. Under WinRT all APIs are exposed as objects that C# and VB can consume directly. This puts .NET developers on level footing with C++ developers.
Application responsiveness is very important to Microsoft. In order to convey that to developers all OS-level API calls that take longer than 50 milliseconds will be exposed as an asynchronous operation.
JavaScript
The fourth major language for Windows 8 is JavaScript. While it doesn’t use XAML, it does have direct access to the underlying WinRT API just like native and .NET applications. This isn’t just a container like PhoneGap, JavaScript developers get the same rich API that other developers use.
Since this is JavaScript the UI toolkit of choice is HTML and CSS rather than XAML. The same rendering engine used by Internet Explorer 10 us used by Metro JavaScript applications, though they don’t actually run in a browser. A JavaScript application looks just like any other Metro application.
User controls in JavaScript are nearly on par with those in C++ and .NET. Some controls are intrinsic to the HTML rendering engine, others are written in JavaScript. These JavaScript based ones are div based much like controls built using jQuery.
App Container and Application Permissions
Metro applications run in what’s known as the “app container”. This appears to replace the windowing environment used by Win32 based applications.
Most API calls are sent directly to the underlying kernel. Some, however, some will be routed through the system broker. The system broker ensures that applications can only access features that the user has approved. For example, the first time an application tries to access the camera the service broker will prompt the user for their approval. Applications are required to include a manifest that indicates all of the restricted services the application may need. This model will be very familiar to mobile device developers.
All Metro applications run within WinRT’s app container and thus are monitored by the system broker, even those written in C++. The idea is to limit the ability of applications to damage the system. While probably not impossible, building malware with WinRT will be much harder than it is in Win32.
All Metro Applications Must be Digitally Signed.
Anonymous applications are not allowed. Applications can be self-signed for testing, but by the time they appear in the app store they will need to be signed using a real certificate.
RelatedVendorContent
Mobile and the New Two-Tiered Web Architecture
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Anatomy of a Deployment Pipeline – free chapter from the book "Continuous Delivery"
Mixed.
by
Walter Horst
Posted
Re: Mixed.
by
Dzmitry Lahoda
Posted
Re: Mixed.
by
Jonathan Allen
Posted
Re: Mixed.
by
Jonathan Allen
Posted
Re: Mixed.
by
Faisal Waris
Posted
Re: Mixed.
by
Jonathan Allen
Posted
Re: Mixed.
by
Walter Horst
Posted
-
Nice Windows gets overhauled and clean up. Some questions though.
1)
"In order to convey that to developers all OS-level API calls that take longer than 50 milliseconds will be exposed as an asynchronous operation."
If a call is done asynchronously or not should not be dictated by the callee, as it's a problem of the caller, hence the caller should be able to decide. Imagine something in some worker thread wants to call any of those potentially long-running methods. It's not on an UI thread or anywhere where blocking is a problem. But now that Windows dictates to use an aysnc method, the caller HAS to handle an async call.
Or are they going to offer both async and sync?
But then again, they could just offer a normal method and the caller will decide how to call it. There are means to convey something to developers other than forcing them to use something with development and runtime overhead...
2)
Now that software development tends to go 'functional' why is Windows going 'object orientation'? I wonder if that's future-proof.
3)
Metro apps have to be signed: I hope this is not going to be 'Apple light' where every poor open-source developer has to jump through potentially costly, but certainly boring hoops to make software available to other people. That would suck. -
Were is link? What is license?
-
> But now that Windows dictates to use an aysnc method, the caller HAS to handle an async call.
While that is the recommended pattern, you can turn any async call into to sync call using the "Task.Wait" method.
> Or are they going to offer both async and sync?
Nope. Looking at the list, it looks like you are only going to get one or the other.
msdn.microsoft.com/en-us/library/windows/apps/w...(v=VS.85).aspx
> Now that software development tends to go 'functional' why is Windows going 'object orientation'?
OOP is still the best way to create extensible data structures. FP just happens to be a really good way of writing the code that glues the objects together.
Fortunately the modern versions of C++, VB, and C# all support both OOP and FP techniques. And of course JavaScript has always had both hidden beneath it's absurd syntax.
> Metro apps have to be signed:
From what I can tell you can simply self-sign the application if you don't want to pay for a code signing certificate. A good thing too, considering that VeriSign charges $895 for a two-year certificate. Hopefully this will encourage other companies to offer more reasonable prices. -
You can download it as part of Windows 8.
dev.windows.com/ -
I have to admit this looks better than what I was expecting.
----
Wonder if async api calls will map well to C# async or the .Net async model (for F#).
---
Promoting XAML to the core is a win for all.
---
Certs are expensive. The prices could be lower but the cost reflects the validation (human effort) certificate authorities need to do before issuing certs. GoDaddy started out by selling SSL certs at very affordable prices but have recently increased the prices - presumably to cover validation expenses. -
The WinRT methods are being mapped to C# async/await syntax. F# hasn't been discussed much, but I would assume the same would be done for it.
www.infoq.com/news/2011/09/DotNet-On-WinRT -
> While that is the recommended pattern, you can turn any async call into to sync call using the "Task.Wait" method.
How inefficient. I want to do a synchronous call, but it _has_ too be done on a different thread and then joined back into the calling thread later.
> OOP is still the best way to create extensible data structures.
Is it? I think it has never been the best way, it just has been 'the way', and slowly more and more OOPers come to the conclusion it doesn't work out. Examples:
* Immutability, being suggested for a couple of years (Lippert, Goetz) because of benefits such as: No need for defensive copying, guaranteed to be thread safe, good testability. But, it doesn't work that well with 'setter' properties, which are the way OOP is done in most languages (C#, Java).
* Composition over inheritance, which is what many Gurus in the c# world are preaching these days.
If you throw away mutability and inheritance, what's left of OOP? Encapsulation and related concepts used by OOP are not specifically OOP, as FP does those, too.
7 comments
Watch Thread Reply