2. Agenda

4. 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

5. Identifying Non Metro SDK API usage
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 Kits8.0App Certification Kitappcert.exe

7. Get the desktop app ready 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

8. Asynchronous operations
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

9. Isolate core logic
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

11. UI
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

12. MFC
MFC not available under Metro
• Rewrite
Options in Metro
• UI
• XAML
• DirectX
• Form based App
• Consider XAML databinding
• Utility classes
• Consider STL, CRT

14. CRT
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

15. 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, …

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

18. Static Libs
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

19. Using existing code in Metro
(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

20. Convert types to WinRT types
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

21. Strategies to create WinRT
component
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

22. Converting COM components to
WinRT technology
Choose the
• 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

23. Technologies to use during porting
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

25. 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