I searched the documentation for the winrt namespace and didn't find any console functions, i.e AttachConsole. I wonder if there is, for a UWP windows console project (C++/winrt)?
UWP has three 'app models':
A XAML app with C# or C++ code-behind
A Direct3D app
A Direct3D + XAML app
There is no support for 'console windows' in UWP.
I've 'faked' a text console for UWP test apps and samples using the Direct3D app model (see directx-vs-templates for the basic render loop), DirectX Tool Kit, and my TextConsole utility.
You can invoke most Windows Runtime APIs from any win32 console applications as well as packaged console applications (a relatively new feature) but there are no Windows Runtime APIs that provide control of the console or console-specific behavior at this time.
Thanks,
Ben (MSFT)
Related
Here's the problem. I have a win32 (x86) program that has WinRT NuGet installed and working that needs to call a C# functions. I followed the instructions here and got everything working as a test C++/WinRT template app (see picture below). However, I followed these instructions to convert a C++ native console app and a C++ native desktop app. Neither of these projects can reference the WinRT Component project directly like the C++/WinRT template can. So I found the output .winmd file and referenced that instead and got both native projects to build. But now I get a different error: REGDB_E_CLASSNOTREG Class not registered == 0x8000000c : A concurrent or interleaved operation changed the state of the object, invalidating this operation.
What's the difference between a converted C++ app and a C++/WinRT template app?
Which part lets the C++/WinRT app reference the WinRT Component directly?
For third-party NuGet packages, is this a possible method to use? Or perhaps I should look into C++/CLI wrappers for this? (I have no experience with C++/CLI wrappers)
Edit
For clarification between the two projects I'm comparing, one is a Windows Console Application (C++/WinRT) which I think I got this option from the the WinRT VSIX extension. The other is the base C++ Console App (Run code in a Windows terminal. ...) that would download the C++/WinRT NuGet package after startup.
Currently I'm working on a simple game engine project. I would like it to be independent from the platform, so for started I've taken only classical Windows Desktop application and Metro Style app.
From this picture:
Windows APIs
We can see that the C/C++ blocks are common for both parts. In other words, I would like to easily switch between platform configurations. I've created simple WinAPI static library that you can easily include in the project, as well as DirectX game-engine and it works perfectly. However, I'm having issues to do the same with WinRT (used in Metro Style apps).
Is it possible to have one Visual Studio project that can use WinAPI or WinRT? It would be perfect if I could have like one single entry point for a game and just switch underlying APIs.
No. A single VS project that either generates a classic win32 exe and a WinRT (nowadays Universal) applications is not possible.
In theory they could have made it possible, like you can have a single project that generates a console application or gui application. The difference between the two boils down to one (or two) flags.
The difference between a classic exe and a WinRT app is quite big: There are manifests and packaging and special sauce signing not to mention the resources (icons, etc) are specified differently.
In the Visual studio UI this is manifested by a different set of property pages, besides the common core of compiler + linker ones of course.
The other reason is one of strategy. Microsoft wants you to move forward and embrace the WinRT API. That is the API set that works across all Windows devices (if you ignore the Win7 elephant in the room). Supporting a dual mode will send the wrong signal to developers.
As a side note that the very windows headers (windows.h) are annotated by API family. CreateNamedPipe is #ifdef out in a WinRT application, or for example there is CreateFile for classic apps and CreateFile2 for modern apps.
I want to know what is the difference between windows form application, win32application ana console, i know that both the windows form application and win32 application is gui tool, but i want to know when to use one over the other one, and could I convert console application to windows form application ?
Windows Form refers to a .NET application. It's not based directly on the native Windows API, but instead on the .NET infrastructure. Which includes a virtual machine.
Win32 generally refers to the 32-bit Windows API. However, the _WIN32 macro is defined for both 32-bit and 64-bit programming. As a Visual Studio project type it includes both GUI and console subsystem API-level programs.
A Windows subsystem is a small integer value in the executable's header that tells Windows what kind of services this program needs. This value can be inspected via e.g. Microsoft's dumpbin program, e.g. dumpbin c:\windows\notepad.exe /headers | find "ubs". In Windows 9x the dumpbin output was available via the file preview functionality, but that feature was discontinued.
Each process in Windows can be associated with one, and at most one, console window.
GUI subsystem means that Windows will NOT attempt to outfit each instance with an associated console window. The process can however create a console window itself. Usually this subsystem is used for ordinary programs with a graphical user interface (hence, "GUI"), and with most linkers it's specified as "windows".
Console subsystem means that Windows will attempt to outfit each instance with an associated console window, creating a new one if necessary.
Note that
The same source code can be built as console or GUI subsystem. And that's extremely easy to do. Just change the subsystem specification.
A GUI subsystem executable has standard streams, just as a console subsystem executable has.
A console subsystem executable can present a graphical user interface, just as a GUI one can.
Also note that
Microsoft's tools will by default not accept a standard C++ main for a GUI subsystem build. However, this non-conforming behavior is easy to fix. Just specify /entry:mainCRTStartup in the linker options.
There is no such problem with the GNU tools, that is, g++.
windows form applications are applications that use the graphical programming interface frameworks such as .NET, DELPHI, or MFC instead of directly calling the win32 API.
On the other hand, win32 application usually deals directly with windows api to create applications from bottom up.
And console applications don't have any graphical interface. Only command line window is used for data input and result output.
A "windows form application" is a GUI .NET app.
A "win32 application" is a native Windows GUI app.
A "console application" is a native app without GUI.
I don't really understand what you exactly mean by "convert" one kind of app to another kind. But. If you are talking about using some IDE and convert a project to another one : YES it is possible. What makes the main difference is the .DLLs you linked your app with. You can configure a project opened as "console" to behave as a "win32" for example. It is not really easy, but it remains possible. Nos if you want to know if a given existing application that you installed can be converted : NO.
I have experimented with XAML UI programming using C++ for Windows 8 Store apps. I really like the developer experience, the XAML designer and the fact that I can get pure native apps with a modern rich user interface and high performance.
I want to create similar XAML apps using C++ for Desktop Windows (the non-Store world). How do I do this? For years I have waited for a native UI stack for Windows Desktop which is newer than MFC and somewhat higher level than direct Win32/GDI programming.
Both Silverlight and WPF use XAML along with code-behind to implement apps. Neither are still maintained but if you want to play with the same technology, it's there.
As Jeff McClintock mentioned, Microsoft has announced that a future update to Windows 8 will allow apps to run on the desktop, but I expect that this will merely be a windowing change and the apps will still run in the restricted sandbox that Store Apps run within. Maybe Microsoft will introduce yet another desktop-based UI framework and support it for three years before killing it.
WTL is newer than MFC, although its last update was six years ago. I personally recommend Qt, as it allows access to native Win32 calls (so you can do whatever ganky stuff Win32 apps normally want to do) while still having a rich, robust UI framework to build upon.
A future update to Windows 8.1 will allow Windows 8 Store Apps to run in a Window on the Desktop, and appear on the taskbar like a Win32 Application. This allows Store apps to Act a lot like Desktop Apps. MS have hinted store-app XMAL will be available to Desktop apps at some point in future.
http://www.gottabemobile.com/2014/04/02/microsoft-listens-to-users-start-menu-and-windowed-apps-are-on-the-way/
Codejock has some markup language support in MFC (native C++).
http://www.codejock.com/inc/img/downloads/samples/toolkitpro_markupsample_full.png
What I am looking at is C++/WinRT for native C++ applications that use the WinRT framework for UWP apps, at least for Windows 10. See C++/WinRT in the Microsoft Dev Center for a starting place.
C++/WinRT is an entirely standard modern C++17 language projection for
Windows Runtime (WinRT) APIs, implemented as a header-file-based
library, and designed to provide you with first-class access to the
modern Windows API. With C++/WinRT, you can author and consume Windows
Runtime APIs using any standards-compliant C++17 compiler. The Windows
SDK includes C++/WinRT; it was introduced in version 10.0.17134.0
(Windows 10, version 1803).
The intro article in the series goes on to say:
For authoring and consuming Windows Runtime APIs using C++, there is
C++/WinRT. This is Microsoft's recommended replacement for the Windows
Runtime C++ Template Library (WRL) and C++/CX.
I first got started with UWP apps for Windows 10 using C++/CX which uses the Microsoft Visual Studio C++ extensions with ref and all of the C# like extensions for C++ in a .NET world.
I am now working with Visual Studio 2017 and the C++/WinRT framework which uses native C++17 features along with an SDK. I believe you can also use C++/WinRT with Visual Studio 2015 with the latest updates, update 3.
There is also a package available from Extensions and Updates within Visual Studio, C++/WinRT, which contains a couple of Visual Studio templates for a couple of different application types.
C++/WinRT seems to be a work in progress. It seems best if you are using Visual Studio 2017 with the latest Windows 10, Version 1803, which contains the SDK and the XAML editor works fine. I have had problems with the XAML editor with an earlier build of Windows 10 Enterprise at work (IT Services maintains its own update servers and is a couple of builds behind the bleeding edge).
See also my question synchronizing SDK with Windows 10 update and using WinRT with Standard C++ which has an updated version of a test program from this article, C++ - Introducing C++/WinRT.
I need to develop common UI which will run on both desktop and metro.
Is this possible.I wanted to use same code for UI both in desktop and metro app
I know that Win RT is Supported on both desktop and metro.
I believe your question is about creating an application that works like both Metro Style and also as a traditional desktop app. What you need to do is to wrap all your business logic code into a WinRT DLL and create two different UI applications one using XAML and another using windows Form and consume the DLL.
But ideally you cant have a single exe that runs like a native app and a metro style app, you should have two exe's.
Another thing is the native app which you develop in this manner may not be backward compatible because in build conference i remember them saying WinRT is only from Windows 8 onwards. so you cant run your native app in Windows 7.