Windows 8 Runtime reference and sample code [MSDN]
msdn.microsoft.com
msdn.microsoft.com
For years Microsoft has been trying to come up with a successor for Win32. This looks like the most credible attempt yet.
I don't think this API will be accessible from standard C/C++, though. All the code samples require Microsoft's C++/CLI dialect.
For example, here's what main.cpp looks like for one of the app samples that uses a Direct3D view:
#include "DirectXViewProvider.h"
[Platform::MTAThread]
int main(array<Platform::String^>^)
{
auto directXViewProviderFactory = ref new DirectXViewProviderFactory();
Windows::ApplicationModel::Core::CoreApplication::Run(directXViewProviderFactory);
return 0;
}
It's certainly a great improvement over the old WinMain() and running your own event loop. However, those ^ symbols indicate managed CLI objects. When these are even in the main() function signature, it suggests that C++/CLI is a hard requirement.I'm not sure how this will affect other compilers on Windows. AFAIK, Visual C++ is the only compiler with C++/CLI compatibility. Will it be impossible to build full apps using GCC on Windows 8?
"In this example, you will immediately notice some keywords that are not part of standard C++. Visual C++ defines a few Component Extensions that, in a Metro style app,are essentially syntactic sugar over the underlying COM calls involved in creating and consuming Windows Runtime types.
"If you are familiar with C++/CLI, you will notice that the Component Extensions look very similar to C++/CLI syntax. However, in a Metro style app or Windows Runtime component, all the C++ code is native. The /Zw compiler option causes the Component Extensions to be compiled for Windows Runtime. The /cli compiler option causes them to be compiled for C++/CLI. Currently, C++/CLI is not supported for Metro style apps."
(Source: http://msdn.microsoft.com/en-us/library/windows/apps/hh45407... )
I'm fairly confused now. So they've added a compiler extension in Visual C++ v11 that compiles this C++/CLI look-a-like syntax into traditional COM types and calls? If so, that's good news for other compilers, I guess.