来至microsoft构建WinRT开发人员的回答

翻译来源：http://www.infoq.com/news/2012/11/Panel-WinRT-Answers

原文：

Panel: Answers from Microsoft Developers Who Built WinRT

Posted by Abel Avram on Nov 05, 2012

Sections 

Development 

Topics 

Windows , 

Windows 8 , 

Operating Systems , 

WinRT , 

Panel

Share|Share on facebookShare on diggShare on dzoneShare on twitterShare on redditShare on deliciousShare on email

Chris Anderson, Chris Guzak, Jerry Dunietz, Kamen Moutafov, Martyn Lovell, Elliot H Omiya, lead developers working on various WinRT components, have taken questions during the BUILD 2012 panel The Windows Runtime Q&A, answering some of the developers’ ardent questions on Windows 8 applications, especially WinRT ones. Following is a digest of the answers to most important questions.

There is one CLR, one set of DLLs, for desktop and Windows Store applications, but a desktop application’s calls do not go the path of WinRT.

WinRT asynchronous calls may create a problem for cases when, for example, someone has to check the name of hundreds of files. An exception is thrown for each call making the debugging experience cumbersome. The team considers solving this problem in the future.

Microsoft is not disclosing any information regarding future versions of .NET or WinRT, but they will do that at some point in the future. All that they can say right now is the “Windows 8 has a version of WinRT in it.”

Opening a file by a Windows Store app will fail if the file is already opened by a desktop app in exclusive mode. To avoid such a conflict one needs to open the file in read mode. The underlying file system is common to both WinRT and desktop apps. 

An async operation is executed on a separate thread that comes from a dedicated thread pool administered by Windows. Care must be taken when firing a large number of asynchronous calls from the UI thread because they can have a severe impact on the application when they all come back. If an application is to run many async calls, then it is recommended to batch their execution so it won’t overload the system.

There is a new type of string in WinRT in order to have a common way that supports the needs of various languages targeting WinRT. A string created in a language -C#, C++, JavaScript, etc. - is not automatically duplicated when passed to WinRT, only a reference is passed for performance reasons, but it can be duplicated when necessary.

The Windows Store certification process covers only the basic tests to ensure an application’s compatibility with WinRT devices, such as Surface, and it is not an exhaustive one. Extensive testing needs to be performed in order to ensure an application behaves correctly when run on a target device.

Microsoft is not providing programmatic access to some of the system’s hardware information – such as the battery level - in WinRT to avoid developers use it to change the application’s behavior based on that. The idea is to let applications have a consistent behavior across devices and system states. The Windows 8 Dev Portal provides some information regarding the devices and Windows versions an application runs on.

It is hard or impossible to write system administration type of applications for WinRT. The system prohibits or limits access to certain system resources.

There is no programmatic way to query or enforce the application that will serve a certain protocol, such as the file protocol setting determining which application plays mp3 files. The decision is left to the user.

Regarding communication between desktop and Store apps, one of the panelists said: “We work hard for that not to work.” The only way to communicate is through protocols and file type association which are under user’s control.

A WinRT application can have multiple views running in separate threads. Windows considers 2 such views as one single application, that meaning an user cannot switch between the views using the system app switching mechanism but a mechanism developed separately for the app.

A Windows Store application can open ports and communicate but not the web server’s port, 80.

翻译：

Chris Anderson, Chris Guzak, Jerry Dunietz, Kamen Moutafov, Martyn Lovell, Elliot H Omiya, 领导开发人员开发各种WinRT组件，在构建2012windowsQ&A运行时面板已解决这些问题，回答一些开发人员对win8应用中关切的问题，尤其是关于winRT的，以下是一些对重要问题的回答的摘要。

这是一个CRT 一个dll的设置对于桌面程序和windows Store应用,但是一个桌面应用程序的调用不使用WinRT的路径。

异步调用WinRT 也许会产生一个问题当cases when时, 例如，去检查数百个文件的名字时，会抛出一个异常会在调试时带来麻烦，这个团队认为他们会在以后解决这个问题。

微软没有透露任何关于未来.net或者WinRT版本的信息，但是他们以后会在未来的某个时间解决这个问题，然后他们就可以说现在“win8 里面有WinRT可以用了”。

如果这个文件已经被桌面程序以独占模式打开了，再使用windows store打开这个文件就会失败，为了避免这个冲突需要以只读模式打开文件，这个相关的文件系统是被WinRT和桌面程序公用的。

一个异步操作线程是运行在一个专门管理windows线程池的线程上，他会维护来大量来至UI线程的异步调用，因为它会在程序有一个严重影响时全部返回，如果一个程序有运行很多异步操作，所以建议批量的去执行它使他不会让系统过载。

为了拥有一个公共方法去支持各种针对WinRT的语言，在WinRT中有了一个新的字符串类型，一个字符串类型在c#,c++,JavaScript等语言中创建，由于性能原因，使用时不是通过WinRT自动复制字符串，只是一个通过一个对字符串的引用，但是它可以在必要的时候复制。

windows store 认证服务只包括基本的对程序与WinRT设备之间兼容性的测试。如表面，而且它是不详尽的。一个全面的测试需要确保程序在有针对运行性的设备上运行完全正确。

Microsoft没有提供任何访问系统硬件信息的方式，如电源电量，在WinRT中为了避免开发者使用它改变基于这些信息的应用程序动作。这个想法是让不同应用程序对于设备和系统状态得到同样的信息。。Windows 8的开发门户网站提供了一些有关设备和Windows版本信息的应用程序。

这是很难或不可能的去写一个WinRT应用的系统管理类型。该系统禁止或限制访问某些系统资源。

没有编程的方式来查询或执行一些有关某些协议的服务的应用程序。如设置确定哪些应用程序播放mp3文件的文件协议，这个决定留给用户。

对于桌面和应用程序之间的通信，一个小组成员认为：“我们做了很多艰难的努力让它不能工作”，只用一种方式通信，在用户的控制下通过协议和文件方式进行。

一个winRT应用程序可以有多个视图运行在单个线程中，windows认为2个这样的视图在单个应用程序中，意味着用户不必在一个使用系统应用选择机制的窗口和一个为单独开发应用程序机制的窗口之间切换。

一个windows sotre应用程序可以打开端口和沟通，但是不能打开网络服务端口，80。