WinU Build error

[VikingExplorer]

Has anyone tried to build this library in a Windows Universal context?

I'm getting:
1>c:\dev\couloir\3plibs\cppformat-2.0.0\format.cpp(740): error C3861: 'LocalFree': identifier not found
1>c:\dev\couloir\3plibs\cppformat-2.0.0\format.cpp(746): error C2065: 'FORMAT_MESSAGE_ALLOCATE_BUFFER': undeclared identifier

Steps to reproduce:

1. Open Visual Studio 2015 Community Edition, update 1
2. Create new project, Visual C++ ->Windows -> Windows Runtime Component (Universal Windows)
3. Add CppFormat source files
4. Build

[vitaut]

I have no idea what Universal Windows is, but since targeting it gives an error for LocalFree which is defined in windows.h, you can probably fix it by defining FMT_USE_WINDOWS_H to 0.

[VikingExplorer]

Thanks. The solution:

#ifdef WIN_U
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
#define FMT_USE_WINDOWS_H 0                   // this section needed to accommodate CppFormat
#define NOMINMAX                        
#include <algorithm>
namespace Gdiplus
{
    using std::min;
    using std::max;
}                                                           // end CppFormat
#include <windows.h>
#endif

[vitaut]

I know what Windows 10 is, I don't know what Universal Window is and why it breaks WinAPI. Anyway, I'm glad that FMT_USE_WINDOWS_H works.

[VikingExplorer]

WinU = WinAPI

[amc522]

Sorry to comment when this issue is closed, but I wanted to clear up some details for @VikingExplorer . First off, universal windows apps != WinAPI. A universal windows app is a Windows application that is meant to be run on windows desktops or mobile devices (Win32, x64, ARM). It was first introduced in Windows 8. Universal windows apps use a subset of the full WinAPI to be as compatible as possible on a range of devices. There are also special libraries needed for running as a windows store app.

When you create a universal windows project, one of the things you'll notice is that the compiler command line has this define added /D "WINAPI_FAMILY=WINAPI_FAMILY_APP". If you create a blank windows project for Windows 10 (or 8), WINAPI_FAMILY is not defined on the command line. So whats the default?

If you look at a file called winapifamily.h (located somewhere in the Windows SDK) you'll see the following bits of code

#define WINAPI_FAMILY_PC_APP               2   /* Windows Store Applications */
#define WINAPI_FAMILY_PHONE_APP            3   /* Windows Phone Applications */
#define WINAPI_FAMILY_SYSTEM               4   /* Windows Drivers and Tools */
#define WINAPI_FAMILY_SERVER               5   /* Windows Server Applications */
#define WINAPI_FAMILY_DESKTOP_APP          100   /* Windows Desktop Applications */

#define WINAPI_FAMILY_APP  WINAPI_FAMILY_PC_APP

#ifndef WINAPI_FAMILY
#define WINAPI_FAMILY WINAPI_FAMILY_DESKTOP_APP
#endif

So by default, a windows executable is defined as a desktop app and has access the range of the WinAPI available to desktops. By defining WINAPI_FAMILY as WINAPI_FAMILY_APP, you are specifying a windows store application, with access to a subset of the WinAPI and possible a bunch of extensions not available to desktop exclusive applications.

To summarize

• WinU != WinAPI
• WinU != Windows 10
• You can target Windows 10 desktops without being a universal windows app

If you read this, hope it cleared some things up. If you didn't, thats ok too. And if I got any details wrong, please correct me.

[vitaut]

Thanks for clarification, @amc522.

[VikingExplorer]

@amc522, I feel compelled to respond because this is muddling the issue. I started developing for Windows in 1990. You provide lots of details, but nothing that really supports your conclusion. The abstraction level is wrong. The big picture is that WinU is WinAPI for the Win10 family of devices.

If one is targeting Windows Desktop, one is not targeting Windows 10 specifically. I have removed text from above, which in retrospective, was an attempt to get C++ developers to consider Windows as a viable target. Arguing about this will undermine the great support we're getting from Victor.

[Spartan322]

@amc522 just explained why the WinU is not the WinAPI itself, but a derivative of the WinAPI to which only Windows 8 and above have any access to. Either way this issue is fixed and we should stop with anymore discussion.

[VikingExplorer]

Spartan, no, he didn't. You both seem to be conflating WinU with Windows Store App. WinU is the current WinAPI. Everything with WINAPI_FAMILY* is part of WinU. WinU is WinAPI for the Win10 family of devices. Anything else is there for legacy support. If you feel discussion should stop, simply do not respond with more confusing statements. Maybe a picture would help:

https://msdn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide

"With Windows 10 you no longer target an operating system but you instead target your app to one or more device families."

[Spartan322]

It seems no one else believes that as far as I've seen (nor do I see how the WinAPI is part of WinU if previous Windows versions can't even support a part of it like the WinAPI and when the WinAPI isn't actually supported naturally on non-PC Windows Operating Systems, don't argue that with me, I don't care and you can't change that), nor do I truly care, and this discussion became useless after the WinU !=WinAPI statement, so what does it matter, the issue was resolved

[VikingExplorer]

:) Spartan, you seem to be having trouble with abstractions. You are conflating "WINAPI_FAMILY*", a preprocessor # define variable, with WinAPI, a completely generic and abstract term meaning "Windows application programming interface". As for the discussion being useless, it was finished 2 days ago with WinU = WinAPI (which is all the detail that Linux people need in this context), and while you claim to not care, you continue to make confusing comments to someone with far more experience in the problem domain.

The take-away that random people should know is that CppFormat is an excellent piece of software, written in standard C++11, and that it's written in such a way as to be compatible with every platform. I've successfully built this library for Windows Desktop, Windows Universal, iOS & Android. It will be some time before I get to OSX and Linux, but obviously, it's compatible with those as well.