Introduction to Windows RT Application Development Lecture notes on training

Http://www.cnblogs.com/lxconan/archive/2012/09/09/2677957.html

Recently, a lecture on the development of Metro Style applications under Windows 8 was made from an architectural perspective. Here are the speeches.

If you have any questions, please correct me.

：

• Slide
• Additional Instructions

1 overview

The title of this article, called Windows RT Introduction instead of Windows 8 Introduction, is to emphasize that this presentation is from the perspective of the developer rather than the general user. At the same time, we are focused on the development of Metro style applications rather than traditional WIN32 applications.

In fact, code examples that use C # or HTML + JavaScript to write a Hello World app are already flooding the Web. But there's only one Hello world that doesn't say you mastered the development of win Rt. From a pro point of view, we should be able to understand the details of the whole thing. Then the first should be his architecture. So write a program to principled.

2 Windows 8 Metro vs. Desktop Mode 2.1 two modes

There are two types of application display modes for Windows 8, defined in Metro_monitor_mode: Traditional desktop mode (mmm_desktop) and Metro mode (Mmm_metro). If you're a Windows phone user, you might be familiar with Metro. In fact, Microsoft started the development of Windows 8 in 2009 with the goal of creating a completely different operating system that was not modelled on the previous operating system at all. The desktop app was then found to be an integral part of the two-part merger. It may be awkward at first, but I expect developers to be proficient with the system in half a day.

Some of the different 2.2 metro and desktop

Since there are two modes, we will naturally focus on their differences. This question should be explained in the frame composition but we can have some intuition first.

2.2.1 Message Loop

The programming of message processing is an important part of traditional desktop applications. You need to write the code that maintains the message loop. For example, in a WinMain call (or its subroutine) you need to write a similar

while (:: GetMessage (&message, NULL, 0, 0)) { :: TranslateMessage (&message); ::D ispatchmessage (&message); }

And before window is created, you must have specified

Wndclass Wndclass; // ... Wndclass.lpfnwndproc = WndProc;

This allows you to determine the flow of a particular message in the WndProc function. For the drawing, you must have accepted the WM_PAINT message, and then performed the area redraw.

But these are hidden in the Metro app, and the details of the message may have changed. You don't see the message loop in the Metro app. All the distribution of the interface messages is hidden in the coredispatcher. So if you use Spy + + to test the Metro app's message loop then you can't catch anything.

2.2.2 Display

In a traditional desktop application, the drawing may be done through GDI,GDI+,DIRECTDRAW,DIRECTX. The same is done by capturing WM_PAINT messages or drawing when the system is idle (for game programming).

The Metro app no longer supports GDI and GDI +, and plotting in the Metro app can only be done through DirectX. Specifically, Direct3D and the newly released direct2d, Direct Write API. So all the drawings for Metro applications are expected to be hardware-accelerated. This kind of drawing is more efficient, frees up the CPU, and generally does not need to deal with complex dirty region Repaint.

2.2.3 Life Cycle

The Metro app does not have the button to close the window. Its life cycle is managed by the system. The system will decide whether to suspend application execution or to completely destroy the application process. This is not the same as in the general sense of a desktop application. (Of course, you can also use the ALT+F4 display to end Metro app execution).

2.2.4 Share & Communication

Traditional desktop applications have multiple means of public or IPC common build. But in metro apps, isolation is a very important concept, the executable part of the application, the runtime, the Isolated storage are independent and cannot be shared. Similarly, traditional IPC mechanisms cannot be used. The interaction of the application can only be done through the built-in contracts, which can be viewed on MSDN:

Http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx

2.2.5 Portability

Most of the support for traditional desktop applications is the processor of the X86/64 architecture. Because the metro environment can be fully operational on the ARM processor is an important feature, so the Metro app can be run on the ARM processor, that is, deployed on both PC and mobile devices.

2.2.6 OS Access

Of course, in order to portability requirements, the application must not be able to cross the win RT abstraction, so Metro is not like the desktop app to access all the Windows API.

3 viewing Windows RT from the Windows 8 API architecture diagram

Our introduction to Windows RT will be expanded around this diagram.

In this diagram, the bottom-most is the NT kernel, on which is the Windows subsystem. In fact NT has at least three subsystems, Windows subsystem, POSIX subsystem (UNIX) and OS/2 subsystem. The POSIX subsystem and the OS/2 subsystem are actually using the Windows subsystem. Different runtimes (orange) and libraries (light blue) are divided on the Windows subsystem, and the top green is the various development languages we use.

This architecture diagram actually illustrates everything. And it eliminates many misconceptions:

(1) The first misconception is that the Windows RT and Win32 are completely separate from INFOQ. This is due to a critical architecture map published by Microsoft, in which Windows RT and Windows subsystems are arranged side by side. It's ridiculous that Windows RT is actually based on the Windows subsystem. First, Windows RT is completely COM-based, and Windows RT takes advantage of some of the existing Win32 APIs, while the rest of Windows RT accesses the NT kernel directly.

(2) The second misconception is c++/cx. C++/CX is Microsoft's recommended way to develop Windows Rt. He mostly hides the complexities of COM. Our follow-up on this question will be explained. The misconception is that C++/CX is actually the C + + CLI. This is actually two completely different things, the C + + CLI is running in a managed environment, and C++/CX is completely native.

3.1 Windows RT only for Metro applications

As you can see from the architecture diagram, Win RT is only used for Metro applications. And adhering to what we just introduced, simple deployment, no shared components, no IPC, and so on.

3.2 Windows RT Build and COM

This is also why Windows RT is built on top of Win32, because COM is an important part of WIN32. This means that:

(1) You can use Windows RT in all previous ways to consume COM, you can use C, you can use ATL or the new WRL;

(2) The WRL is fully compliant with the traditional C + + syntax, which means you can use different compilers (such as the Intel C + + compiler) to build Metro applications. But Microsoft obviously wants everyone to use C++/CX,WRL's documentation, and there's not a complete example of it.

3.3 Windows RT restricts calls to the system API

Win RT is COM-based, but COM is just a binary protocol. The Win32 API is technically called in the COM interface implementation. However, due to the design requirements of the win RT described earlier, the system API calls need to be strictly limited. Only support Limited API calls, so when you want to use a WIN32 API, be sure to query the applied to section on MSDN to see if it's Metro Style APP | Desktop APP.

The same truth. NET some of the methods are also in the system call, so in use. NET when developing Metro style applications, not all assemblies can support it. Of course, if the Win32 API is called using P-invoke, then the risk will be greater.

In summary, calling an unsupported Win32 API in a Metro application would have the following consequences:

(1) a runtime Exception occurs;

(2) The application loses its response, especially when using code related to message loops. For example, use WaitForSingleObject (hprocess) for the Metro app process.

(3) The call succeeds, but your Metro app will be dismissed by Windows store.

Based on the above analysis, even if you have a considerable number of COM code libraries, it will take a lot of effort to ensure that they run correctly on the Metro app (eliminating illegal system calls). For new applications, to avoid writing large amounts of COM development code, it is best to use C++/CX for development.

3.4 c++/cx

Why do you have c++/cx? This can be reminiscent of n years ago we designed to avoid the tedious code of C + + developing COM, instead using C to develop critical programs, and use Visual Basic to create COM components. Now that the time is up to 2012 years, VB6 is not in the range of consideration, so C++/CX replaced his position.

C++/CX is native, but why is its syntax consistent with the C + + CLI? This is because the win RT itself though is native, but it takes. NET-compatible approach exposes metadata. But we should always think in programming that we are manipulating real deal's native objects. There is no garbage collector at all to help us.

So why not use it purely. NET development Metro app? This is because for mobile devices, the speed of the CPU and the battery are two major limitations, so in the last year, the Go native tide finally hit. Currently

(1) iOS uses OBJECTIVE-C for program development, and there is no garbage collector on the mobile device, need to manually release the memory used;

(2) Android started using Java to develop, but in the poor performance and strong community pressure, finally opened the C + + development interface;

(3) Wp7/8 also appeared in Android-like situations.

Client applications are now moving to thinner (core applications move to the server), faster (faster running, less power consumption), richer interactions (no animations you're sorry for the audience). Therefore, the open native interface is the trend of the general, C + + logical in Windows 8 strong regression.

However, using. NET to develop Metro applications is also a good choice, especially if your application does not have intensive operations (games). You can refer to the cheat Sheet in the slide.

Introduction to Windows RT Application Development Lecture notes on training