I’ve decided to take a more patient approach to learning C++ for Windows Store Application development so I’m starting over, and this time I’m going to make more informative choices based on research. My first stop is Test Driven Development (TDD) in the creation of a ADO.NET like wrapper for SQLite so that I, and other C# developers, can feel a wee bit more at home in working with SQLite.
Creating the Unit Test project was simple enough, but when it came time to create the C++ DLL that would hold the business and data logic layers, I was greeted with a number of options – most of them not applicable to the environment I am targeting and it was not clear to me which template was the best choice.
C++ Version distinctions
Before diving into the different project template types it is important to understand the differences between the versions of C++. I will be targeting C++ 11 using WRL extensions.
- C++ 98 …. Approved in 1998 :: ISO/IEC 14882:1998 – the first C++ standard
- C++ 03 … “Technical Corrigendum” (“TC”), contained bug fixes :: ISO/IEC 14882:2003
- TR1 …….. contains library extensions for the first standard "”Information technology – Programming
Languages – Technical report on C++ library extensions :: ISO/IEC TR 19768:2007 (std::trl)
- C++ 11 … Approved in 2011 :: ISO/IEC 14882:2011 - new and second C++ Standard
- C++ 0x … Synonymous with C++ 11 – this title was used with the expectation it would have been
completed no later than 2009.
- C++/CLI ,…language extensions provided for targeting the CLR (.NET in figure 1)
- C++/CX …. language extensions provided for targeting the WinRT APIs (WinRT figure 2)
- The C++/CX does not use the CLR or a garbage collector
- The C++/CX generates native code
- WRL ……. Windows Runtime Library is a template library that targets Windows 8 without
"In almost all cases, when you want to create a DLL for use in a Windows Store app, create it as a Windows Runtime component by using the project template of that name. " (see WRC below for more details)
Managed Code C++ Code
If you are creating a library that can be used by C++/CLI or any other .NET language such as C# or VB.NET, you are creating a managed assembly.
Native C++ code - DLL and LIB
From a C# perspective the distinction between the DLL and a LIB (at ten thousand feet) can be compared to a C# Class Library project that is included in a solution (C++ Static Linked Library, aka LIB) versus simply added as an assembly reference (C++ Dynamic Linked Library, aka DLL). A project that is included in the solution has all of the source code and is less likely to have versioning issues should the project code change but will be larger in size and contain all source, even if only one function from the library was required.
The more technical definitions follow:
DLL - Dynamic Link Library (Windows Store App)
You can use Visual Studio to create either a standard Win32 DLL or a Windows Runtime component DLL that can be consumed by Windows Store apps. A standard DLL that was created by using a version of Visual Studio or the Visual C++ compiler that's earlier than Visual Studio 2012 may not load correctly in a Windows Store app and may not pass the app verification test in the Windows Store.
LIB - Static Library (Windows Store App)
A static library that's used in a Windows Store app can contain ISO-standard C++ code, including STL types, and also calls to Win32 APIs that are not excluded from the Windows Store app platform. A static library consumes Windows Runtime components and may create Windows Runtime components with certain restrictions
Excerpt From http://msdn.microsoft.com/en-us/library/1ez7dh12(v=vs.120).aspx
A dynamic-link library (DLL) is an executable file that acts as a shared library of functions. Dynamic linking provides a way for a process to call a function that is not part of its executable code. The executable code for the function is located in a DLL, which contains one or more functions that are compiled, linked, and stored separately from the processes that use them. DLLs also facilitate the sharing of data and resources. Multiple applications can simultaneously access the contents of a single copy of a DLL in memory.
Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable.
Using dynamic linking instead of static linking offers several advantages. DLLs save memory, reduce swapping, save disk space, upgrade easier, provide after-market support, provide a mechanism to extend the MFC library classes, support multilanguage programs, and ease the creation of international versions.
WRC - Windows Runtime Component
In almost all cases, when you want to create a DLL for use in a Windows Store app, create it as a Windows Runtime component by using the project template of that name. You can create a Windows Runtime component project for DLLs that have public or private Windows Runtime types. A Windows Runtime component can be accessed from apps that are written in any Windows Runtime-compatible language. By default, the compiler settings for a Windows Runtime component project use the /ZW switch. For more information, see Creating Windows Runtime Components in C++.
The WRL enables you to more easily implement and consume Component Object Model (COM) components. It provides housekeeping techniques like reference-counting to manage the lifetime of objects and testing HRESULT values to determine whether an operation succeeded or failed.
The purpose and design of the WRL is inspired by the Active Template Library (ATL), which is a set of template-based C++ classes that simplify the programming of COM objects. Because WRL uses standard C++ to wrap the Windows Runtime, you can more easily port and interact with many existing COM components written in ATL to the Windows Runtime. If you already know ATL, you might find that WRL programming is easier.
The Active Template Library (ATL) is a set of template-based C++ classes that let you create small, fast Component Object Model (COM) objects. It has special support for key COM features, including stock implementations, dual interfaces, standard COM enumerator interfaces, connection points, tear-off interfaces, and ActiveX controls.
My take on ATL is that it was used with MFC and is provided for backwards compatibility (I don't see new guidance on ATL in the MSDN libraries). It is important to not reference any non-WinRt API calls for the reasons noted in the following excerpt:
I have Windows library developed in C++ that uses ATL collections, ATL CString and COM interfaces with CComPtr heavily. I removed all non-winrt-allowed API calls from the library, and it builds fine, so I wrapped the library in a C++/CX ref-class and I am trying to use it from a Windows Store App. The application runs fine, but the Win-Store App certification fails with the following error: read more
The .NET Framework provides a run-time environment called the common language runtime, which runs the code and provides services that make the development process easier.
Compilers and tools expose the common language runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
The Microsoft Foundation Class Library is an application framework for programming in Microsoft Windows. Written in C++, MFC provides much of the code necessary for managing windows, menus, and dialog boxes; performing basic input/output; storing collections of data objects; and so on. All you need to do is add your application-specific code into this framework. Given the nature of C++ class programming, it is easy to extend or override the basic functionality that the MFC framework supplies.
The Microsoft Foundation Class Library (MFC) encapsulates, or "wraps," much (but not all) of the Win32 API. MFC versions 2.x and earlier encapsulated the 16-bit Windows API. MFC supplies classes representing key Windows objects, such as windows, dialog boxes, brushes, pens, and fonts. The member functions of these classes wrap most of the important Win32 API functions associated with the encapsulated object. The MFC class member function calls the Win32 API function, and might add functionality.
The Win32 application programming interface (API) provides building blocks used by applications written for the Microsoft Windows operating system family. The Win32 API defines the 32-bit members of the Windows family from the programmer's point of view. Some members of the Windows family use the entire Win32 API, while others use subsets. For details, see Windows 95/98/Me Limitations.
Note in figure 1 below that Win32 and WinRT (Windows 8 store apps) are two separate APIs. Windows 8 APIs do include a "subset" of Win32 (ref figure 2) but it is not the actual Win32 API used by Desktop Apps.