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.