This project is read-only.

Any hint as to when this could be complete?

Aug 1, 2014 at 6:07 PM
My company is less than a month from shipping a WinRT game. Right now, our build system uses cmake to somewhat generate a winrt project. Then Python is used to fix what cmake created. It's working okay, but less than optimal. I was excited to see MSFT actively working to get cmake compatible with winrt. I was underwhelmed when I downloaded and installed the latest release, but maybe that's just a documentation issue.

Here are relevant details of our current (automated of course) process.

We have to copy all content files to the project folder in the directory structure we wish to release with.

We do the following for the later Python script to work:
set_source_files_properties(${DATA_FILES} PROPERTIES HEADER_FILE_ONLY true)

We set the following which seems to be the only winrt stuff in cmake currently:
set_target_properties(${APP_NAME} PROPERTIES COMPILE_FLAGS "-ZW")
Then in python, we do the following search&replace actions for the project file:
    '<PropertyGroup Label="Globals">',
    '<PropertyGroup Label="Globals"><AppContainerApplication>true</AppContainerApplication>')

    '<PropertyGroup><PackageCertificateKeyFile>' + os.path.join(common.projectPath, 'build', 'winrt','Slots_TemporaryKey.pfx') + '</PackageCertificateKeyFile>')

    '<ClInclude Include="(.*)Slots.appxmanifest" />',
    '<AppxManifest Include="\\1Slots.appxmanifest"><SubType>Designer</SubType></AppxManifest>',

    '<ClInclude Include="(.*)" />',
    '<ClInclude Include="\\1"><DeploymentContent>true</DeploymentContent></ClInclude>',
Then in Python, we do the following complex search&replace for the .sln file to set the project to be deployed:
for config in allConfigurationCaps:
    slnDeployProjectPattern = '     \{' + slnProjectGuid + '\}.' + config + '\|Win32.Build.0 = ' + config + '\|Win32'
    slnDeployProjectReplace = '     {' + slnProjectGuid + '}.' + config + '|Win32.Build.0 = ' + config + '|Win32\n      {' + slnProjectGuid + '}.' + config + '|Win32.Deploy.0 = ' + config + '|Win32'
    slnContents = re.sub(slnDeployProjectPattern, slnDeployProjectReplace, slnContents)
Obviously, that last loop will have to be more complex once there's more than just win32.
Aug 3, 2014 at 8:08 PM
Hi Ted,

Thanks for your interest in our project.

We are working with Kitware to get these changes integrated and are looking for more test cases before calling it complete. We have successfully built OpenCV as a WinRT library and keep looking for more real world projects that we can validate.

Looking at your issues, most of those should be handled with the current installer that is available for download.

Setting the initial WinRT properties are support and that should be independent of your Python script.

Have you taken a look at the Tests\VSWinStorePhone project, this shows the Sample DX Windows Store project working with CMake with the necessary settings.

Setting the AppContainerApplication flag is handled when you set the CMAKE_VS_TARGET_PLATFORM to be WindowsStore (as well as the other necessary flags).
Adding the Package certificate is also handled if you set the file as VS_WINRT_CONTENT.

The deploy target should also automatically get set for you.

Feel free to contact me privately and we can figure out how to make this work better for you and what else is missing from the project to make work with all the different types of projects out there.

Aug 3, 2014 at 10:10 PM
So that test isn't in master but is in MSWinRTPhoneStore and in MSWinRTStorePhone. Is the installer built from one of these other branches instead of master?

I'll try out the installer using that test as my docs.
Aug 3, 2014 at 10:23 PM
Yes, the installer is based on the MSWinRTStorePhone branch since that's where all our work is happening.
Aug 4, 2014 at 1:06 AM
Deploy wasn't set in the solution configuration. Other than that, it seemed to work quite well.

I say "seemed to" because it won't compile now, which is what I would expect since we're (indirectly) using illegal API calls. Everything works fine, including at runtime, if I compile the illegal calls into a non-winrt lib then link to that. But apparently using this proper winrt-compatible cmake catches the API calls at build-time. It's a shame MSFT could have and should have created implementations of their illegal API calls and mark them obsolete; instead we have lots of work ahead of us. (FYI - basic stuff like CreateThread, CreateSemaphone, WaitForSingleObject, etc.)
Aug 5, 2014 at 3:49 PM
I'll double check the deploy settings.

For the APIs, you can disable them if you remove the AppContainerApplication from the project. This will let you compile and run but will fail ingestion, so it is only a temporary unblock if you need to use it.
Aug 5, 2014 at 6:25 PM
FYI, our company has already been meeting with MSFT. Matt Booty, Andrew Adamyk, and others. 2 of us 3 founds worked at MSFT Game Studios for 5+ years.

I could format this prettier, but this gets the point across:
CoCreateInstance in ole32.dll CoInitialize in ole32.dll CreateEventA in kernel32.dll CreateSemaphoreA in kernel32.dll CreateThread in kernel32.dll DebugBreak in kernel32.dll ExitThread in kernel32.dll GetExitCodeThread in kernel32.dll GetModuleHandleA in kernel32.dll InitializeCriticalSection in kernel32.dll LoadLibraryA in kernel32.dll OutputDebugStringA in kernel32.dll SetThreadPriority in kernel32.dll Sleep in kernel32.dll SwitchToThread in kernel32.dll TlsAlloc in kernel32.dll TlsFree in kernel32.dll TlsGetValue in kernel32.dll TlsSetValue in kernel32.dll WaitForSingleObject in kernel32.dll GetForegroundWindow in user32.dll GetMessageA in user32.dll PostThreadMessageA in user32.dll timeGetTime in winmm.dll waveInAddBuffer in winmm.dll waveInClose in winmm.dll waveInGetDevCapsA in winmm.dll waveInGetNumDevs in winmm.dll waveInOpen in winmm.dll waveInPrepareHeader in winmm.dll waveInReset in winmm.dll waveInStart in winmm.dll waveInStop in winmm.dll waveInUnprepareHeader in winmm.dll waveOutClose in winmm.dll waveOutGetDevCapsA in winmm.dll waveOutGetNumDevs in winmm.dll waveOutOpen in winmm.dll waveOutPrepareHeader in winmm.dll waveOutUnprepareHeader in winmm.dll waveOutWrite in winmm.dll

Here's what I did to fix this so far:

define CreateSemaphore(attributes, count, maxCount, name) \

CreateSemaphoreEx(attributes, count, maxCount, name, 0, SEMAPHORE_ALL_ACCESS)

define InitializeCriticalSection(section) \

InitializeCriticalSectionEx(section, 0, 0)

define WaitForSingleObject(handle, timeout) \

WaitForSingleObjectEx(handle, timeout, TRUE)

define GetExitCodeThread(handle, code) \

((*code) = 0)

We're currently stuck on getting OpenAL to compile ( for winrt. DSound backend is unsupported. There are two other Windows backends, but they appear to use lots of non-WinRT APIs.

Another project has simply decided it's easier to be single-threaded than figure out how to do cross-platform threading with winrt:
Aug 12, 2014 at 5:53 AM
I'm not sure what changed, but 'deploy' is being set in the sln file now. I also have our code fully complying and passing the cert tool, but only by disabling openal and libcurl. IOW, now the game works and could release but no audio or networking ... so it can't release. If I can't find a winrt version of these, I'll be sprinkling some #ifdef WINRT along with calls to WinRT APIs in.

But I am very happy to report automated winrt build with no search&replace hacking and even passing local cert.
Aug 12, 2014 at 4:54 PM
I'm very happy to hear this this is working well. For libcurl, what are the building issues that you are seeing? If it is about sockets. VS 2013 Update 3 that was released last week enables sockets in 8.1 projects. Perhaps that might help.
Aug 12, 2014 at 9:20 PM
I can't find any information about Update 3 & sockets. I'd love to find out more.

Same code compiled fine on Win32 but on WinRT SOCKET is undefined. If I include <winsock.h>, it's all (properly) #ifdef'ed out so it doesn't change anything. If I include <winsock2.h>, which appears to enable some parts of WinSock2, then I start getting new D8048 errors about .c files being compiled with /ZW. It's as if something included by <winsock.h> is altering how completely unrelated files are being compiled. I'll have to set this aside for a few more days and get back to it later.
Aug 19, 2014 at 6:03 AM
Hi Ted,

I just saw your message. Here's a link to get Update 3.

This should allow you to use Sockets in a WinRT project.
Aug 19, 2014 at 8:49 AM
I like what I see at
I also noticed some C++-specific thread-local-storage coming in VSvNext.

I'll let you know what I discovered about sockets & libCurl when I get back to this task.

Why do I always have to re-auth on codeplex? I never enter credentials, just click login then MSFT-account. I don't think this browser has crashed or otherwise invalidated stored credentials. Just a bit of feedback for the CodePlex team.
Aug 26, 2014 at 12:29 AM
Edited Aug 26, 2014 at 12:31 AM
I'm back on this task, and it appears that one issues I'm hitting (*) has just been fixed. Though I won't get it until there's a new build.

libcurl & libwebp both had this issue, fyi.
Aug 26, 2014 at 2:02 AM
libcurl is rather close. After a challenging config I'm down to unresolved externals. Some of these may be allowed in WinRT and I just have to find the right .lib to link to, but I doubt it since this all compiles fine for win32. I had to disable LDAP and Crypto support, fyi.

I'm sharing all this in the hopes that you can share it effectively within MSFT to illustrate why the Windows Store lacks quality games. (Paying DIS $M's to port theirs doesn't count, btw.)

Aug 26, 2014 at 6:01 PM
After doing fun things like #define getenv(var) (var);(NULL), it all links and cert only fails with the following:

API CreateThread in kernel32.dll is not supported for this application type. Slots.exe calls this API.
API FormatMessageA in kernel32.dll is not supported for this application type. Slots.exe calls this API.
API Sleep in kernel32.dll is not supported for this application type. Slots.exe calls this API.

Then I get to either fix openal or write an audio layer that uses xaudio2. It could be worse. I could still be using Unity.
Aug 30, 2014 at 12:38 AM
Figured out libcurl.
Can't use openal, so built another audio system for winrt (xaudio2).

Update to latest (Aug 14?) cmakems version, everything is good except Visual Studio 2013 & -DCMAKE_SYSTEM_VERSION=8.0 results in errors. Cmake tries to identify the compiler using a VS2012 project, which I don't have or want. I assume that I have to build for 8.1 to use sockets. If I don't then there is no reason for me to further limit my potential customer base by requiring 8.1 instead of just 8.0. Similarly, we support Android back to 2.? and iOS back to 5(4?).

Now due to a logging system we integrated, I need to fix the following undefined things:
And my favorite ... NULL

I see no reason that most of these could not be supported on WinRT with caveats such as "Won't work on ARM." and "Obsolete API. As of January 2015 we will reject submissions that use these APIs." or (e.g. for getenv) simply "On WinRT, always returns NULL."
Sep 2, 2014 at 12:28 AM
This thread is clearly too long, but here's the latest. Not related to cmake at all, but libcurl+https. sspi.h is wrapped in a big #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP). I have little hope that OpenSSL is WinRT-compat:
Sep 2, 2014 at 3:39 AM
Thanks for all the feedback Ted? This is really appreciated. We have made changes to openSSL for Windows phone and Windows store. I've got a couple of little things left to do before trying to get them integrated in the openSSL code base. I can share a patch if you are interested.
Sep 4, 2014 at 5:22 AM
The latest build works wonderfully. No more hacked or manual WinRT build steps. :)

I'd love to see OpenSSL on WinRT. It's a daunting codebase. For an individual company, it's easier to #ifdef to HttpClient (or whatever) for winrt like I did for openal/xaudio2. But if MSFT could get OpenSSL to work on WinRT, it saves us all from these #ifdef code paths.