Porting to MetroSridhar MadhugiriSoftware Design EngineerMicrosoft Corporation

Agenda

Metro SDK API

Prepare for porting

Win32 technologies

Libraries

Porting

Metro SDK API

WinRT API• New APIs• Operation that can block implemented as asynchronous operation

Win32 API• Subset of Win32 API available in Metro• Similar Win32 API may be part of Metro SDK• InitializeCriticalSectionAndSpinCount -> InitializeCriticalSectionEx

COM Components• Some OS components available under Metro

Metro SDK API

Documentation• http://msdn.microsoft.com/library/windows/apps/br211369

Preprocessor define• WINAPI_FAMILY=WINAPI_PARTITION_APP• Add the define to C++ preprocessor settings in Projects settings• Compiler stops after 100 errors so may not get full list API not available in Metro

SDK

Windows App Certification Kit tool• Create an Appx package with app binaries• Run resulting package through tool• <Program Files>\Windows Kits\8.0\App Certification Kit\appcert.exe

Identifying Non Metro SDK API usage

Prepare for Porting

Build with VS 11• Compile, test on Windows 8 desktop

Desktop API usage• Use alternate Win32 APIs available in Metro SDK• Wrap API usage in abstractions

Get the desktop app ready for Porting

WinRT APIs are asynchronous• Refactor existing code to consume asynchronous operations• DO refactor code to deal with partial data• DO keep UI responsive while asynchronous operations are in progress

Convert long running operations to asynchronous• Schedule long running work on thread pool• DO return partial results as and when available• Options• Rewrite existing code• Write a wrapper that invokes existing code on a thread pool thread

Asynchronous operations

Separate platform specific code into abstractions• Refactor direct call to APIs to call an abstraction over the API• Use existing abstraction in libraries if available

Use Standard C++ libraries for core logic• Refactor core logic to operate on buffers, containers, etc

Isolate core logic

Win32 technologies

User and GDI based UI• Rewrite

DirectX UI• Available in Metro• Use DirectX template as starting point• Template sets up the start up code required for Metro

Options for UI in Metro• XAML• DirectX

UI

MFC not available under Metro• Rewrite

Options in Metro• UI• XAML• DirectX

• Form based App• Consider XAML databinding

• Utility classes• Consider STL, CRT

MFC

Libraries

Subset available in Metro• APIs for concepts not available in Metro not available in CRT

APIs available in Metro but not recommended• File api• ANSI char functions

CRT

APIs not in Metro• Multi-byte functions: mb* and _ismb*• Process control: exec* and spawn functions• Threading: beginthread* and endthread*• Heap and stack functions: heapwalk, heapmin, resetstkoflw(), …• Environment variable functions and globals putenv, getenv, _enviorn, …• Console function, cprintf, cscanf, …• Port functions, outp, inp, …• Pipe functions: pipe, popen, pclose, …

CRT

Subset available in MetroAPIs available in metro• DLL server• COM objects (without IDispatch)• CStringW• ATL container classes• CCriticalSection, CEvent, CMutex, CSemaphore, CMutexLock • CComVariant• CComSafeArray• CComBSTR

ATL

Porting

Consumption of WinRT in static libs• C++/CX – supported• WRL – supported

Authoring WinRT component in static libs• C++/CX – not supported• WRL – partially supported• Have to take explicit steps to make sure that component is part of the final binary• WrlCreatorMapIncludePragma used to make sure that specific class is pulled in

from static lib

Static Libs

(or do I need to convert all my code to WinRT components)

C++ Metro Apps can use existing static libs, DLLs and COM components• DO make sure that the existing code is ported to use Metro SDK APIs• Link to static libs or import library as usual• Include binary components in APPX package, DLLs are app local

Using COM components• Use Reg-Free COM for activation• Activation through new API - CoCreateInstanceFromAppx

Using existing code in Metro

DO change variable to WinRT type if• It frequently crosses boundary AND • Costly to convert between the two types• String and Array as input parameters to WinRT API can be efficiently converted

without copying• StringRef, ArrayRef add a WinRT veneer using “borrow” semantics

Container and Collections• Requires copy to go from std::* to Platform::*• std::* efficient compared to Platform::*• Use std::* or Platform::* based on how often collection contents change vs how

often they cross WinRT boundary

Convert types to WinRT types

Choose technology• C++/CX, WRL, Your own implementation

Wrapper• Define interface and in the implementation delegate to existing C++ code after

any type conversions• Creates a WINRT veneer over your existing code

Covert existing code • Rewrite code to use WinRT types and concepts• Have good reasons to go this route

Strategies to create WinRT component

Choose the technology• C++/CX, WRL, Your own implementation• Component already written using ATL, may be easier to move to WRL

Steps• Create WinRT interfaces corresponding to the previous interfaces• Port to one of the above technologies• Generate WinMD (if using IDL, modify MDIL flags)• Ship DLL and WinMD for others to consume the component

Converting COM components to WinRT

Language and Libraries• CRT and STL for utility functions and classes• C++/CX and/or WRL to interact with WinRT• See other talks for details about C++/CX and WRL

UI• XAML• DirectX

Technologies to use during porting

Conclusion

Metro SDK• Work involved to move but not all throw away• Lot of the business logic, core application logic is portable

UI• DirectX – easy• Win32 – rewrite in C++ using Modern UI framework

C++• Two way to interact with WinRT C++/CX, WRL• Use familiar C++ concepts and types for parts that don’t directly interact with

platfrom

Build, test, validate often• Use Release configuration

Conclusion

© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.