Porting cross-platform C++ libraries to Windows Phone 8 platform

Question

I've searched the web and StackOverflow a lot, but can't seem to find a definitive answer to my following questions.

Context:

I am looking to port a group of C++ helper libraries for use with the Windows Phone 8 (WP8) platform. Historically, these libraries are built as static libs (rather than DLLs).

I have successfully written the WP8-specific code, so that the libraries are compatible and building against ARM, using the APIs available to WP8 (using the WP API QuickStart doc as a reference point). Only one of the libraries (e.g. Lib1) requires consumption of the WinRT extensions (the /ZW flag), due to having to replace the classic Win32 Thread calls with WinRT's ThreadPool.

When building Lib1, I get the following warning: Warning 1 warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata.

— searching for this warning, I found this article, stating: "If you consume a static library that creates public ref classes, public interface classes, or public value classes, the linker raises this warning. You can safely ignore the warning if the static library is not producing Windows Runtime components that are consumed outside the library itself. Public components in a static library will compile but will not activate at run time. Any Windows Runtime component that's intended for consumption by other components or apps must be implemented in a dynamic-link library (DLL)."

In Lib1, ClassA contains the functions using WinRT ThreadPool calls. ClassA functions are called by ClassB, and they simply return regular HANDLEs and DWORDs to ClassB.

Code example:

// ClassA.cpp
HANDLE WINAPI ClassA::CreateThread(/* Params that are usually passed to Win32 CreateThread */)
{
    // Do WinRTThreadPool stuff to create WorkItem
    auto workItem = ref new Windows::System::Threading::WorkItemHandler([=](Windows::Foundation::IAsyncAction^)
    // More code that eventually results in a Win32 Handle

    return handle;
}

// ClassB.cpp
Handle handle = ClassA::CreateThread(/* Params that are usually passed to Win32 CreateThread */);

ClassA's functions will only ever be called by ClassB, from within Lib1, and ClassB can then be used by the application linking Lib1.

Finally, to my questions:

1. Can the C++ libraries that do not consume WinRT extensions (/ZW), when built as static libs, be used by Windows Phone 8 applications?

2. Can the C++ library (Lib1) that does consume WinRT extensions (/ZW), when built as a static lib, be used by Windows Phone 8 applications, despite the warning?

3. If the answer is no to either question, will I have to create WinRT Component wrappers for all of the classes in the respective library, like this article demonstrates with the Mandelbrot Algorithm? Or is there something else I'm missing?

Thanks in advance for any input you can provide.

Answer 1

Question 1 Yes, as long as you're not using any APIs that aren't allowed on the phone, eg Win32, MFC, etc. Some of the standard c features have some constraints around them; for instance you can only call fopen on files that are in your applications local area. Of course, you can only access the functionality in your static lib from C++ code. This scenario is what I like to call the "Plain Old C++" scenario. It works fine.

Question 2 Yes, as long as any ref classes that you define in that static lib are only intended to be used from within that static lib. So in your example, as long as Class A is a regular old C++ class, you will be fine. Essentially you can't have ref classes that are public in the same sense as public classes in a .NET assembly, because that requires some COM-on-steroids magic, and that only gets compiled into Windows Runtime Components. If you have plain old C++ code that wraps around your calls to any ref class code, and the code that consumes your static lib consumes it in a plain old C++ way, then you're fine. Logic suggests that you won't be able to pass WinRT types out of the static lib, although I haven't tested that assumption yet.

Question 3 I believe the article that you reference misses the fact that code in a static lib can access ref classes etc, so don't worry, you don't have to write Windows Runtime Component wrappers around your static libs. You only want to do that if you want the code in your static lib to be available via "Public Classes" (in the .NET assembly sense).

The thing to remember is that you're still building a static lib "for the windows store". It is native code, but it can still do all the C++/CX stuff, it just doesn't include the COM activation stuff to allow the types defined within it to be accessible outside of the statically linked C++ scenario.