I want to use Boost C++ in a Windows 8 Metro app and I can't get the library built on Windows 8 via Visual Studio 11 in the Windows 8 Developer Preview. I believe this is due to the limited out-of-the-box functionality on VS 11 at this time.
The latest version of Boost (1.48.0) does not come with an installer.
Does anyone have a solution for this?
If the answer is build on Windows 7 and transfer, how do I accomplish this?
Boost C++ download: http://www.boost.org/users/download/
Boost C++ getting started: http://www.boost.org/doc/libs/1_48_0/more/getting_started/windows.html
A Metro library and a desktop library are different things. Metro libraries are severely restricted. You could build the library on Windows 7 and hand-install it on your system, but that would not mean you could use it on your system from a Metro app, if it made system calls that Metro does not allow.
Rather than "all of Boost" you would be best served by trying to get the pieces you need working. If you don't use Boost to work with files, what do you care that file access must now be async, and must go through APIs that ensure your Metro app has declared the right capabilities, and so on? And of course if you are using part of Boost that is in C++11, (eg shared_ptr) save yourself a lot of trouble and use the C++11 version.
Related
Can we use ninja to build UWP apps and hence create the appx package for the same?
I don't feel there is an online article for the same. I know how to do it using VS and Make.
In theory: Yes
Notable one thing: Ninja just official support C++, I can't find any result Ninja support other programming languages
With C++ we have 2 options:
C++/CX: You should activate flag /ZW for Windows Metadata
C++/WinRT: With WinRT you just compile without any restrict, this doesn't need Windows Metadata anymore
C++/CX: we have long story behind Windows Runtime development before C++ 11/14 became official so Microsoft add their own implementation features to MSVC. So with C++/CX you can compile with very old SDK like 10240, 10586, ... and in theory it also work with Windows 8.0/8.1 SDK, Windows Phone 8.0/8.1 SDK. Another attemp try to compile UWP with C++/CX on FastBuild (system build like Ninja) is successful, you can read as a reference here: https://github.com/fastbuild/fastbuild/issues/623
C++/WinRT is reunion attempt make Windows Runtime back to standard C++ 17. C++/WinRT can also compile with Clang/GCC. Base on answer from Kenny Kerr (creator of C++/WinRT): C++/WinRT is not limit with old SDK, but he recommended to use newer SDK like 17134. Link his answer https://stackoverflow.com/a/53193711/8707331.
Some useful links for C++ UWP:
https://github.com/MicrosoftDocs/cpp-docs/blob/master/docs/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app.md
https://modernwindows.wordpress.com/2015/05/28/modern-c-and-clang/
you can create uwp apps in following ways:
c# and xaml
web technologies like html, css and js. and you can use any
third party js libraries with it. you can even use hosted web apps
as uwp apps or latest technologies like pwas can also be shipped as
uwp apps. more here : https://developer.microsoft.com/en-us/windows/pwa
c++ and xaml : with this approach you can use c++ libraries (if they comply by uwp platform) the reason you do not have much support online for this is because majority of uwp developers use c# and xaml approach.
There are some work around for that, and one of them is to create a Desktop app and then package that in MSIX packaging , which packages a windows Desktop app into a uwp app and you can even distribute it through Microsoft store.
CMake can't be used to generate UWP package. However, you could use make.exe or Visual Studio to generate UWP package. For more you could refer to Create an app package with the MakeAppx.exe tool and Package a UWP app with Visual Studio.
Background:
I'm programming a plugin (basically a dll) for an x64 application.
More specifically this x64 WIN application comes with a "plugin manager" (a dll) that loads and unloads 3rd party plugins (like mine).
My plugin is written in C++ and I decided to compile it with mingw-w64. As IDE I've choosen Code::Blocks.
I tried to avoid MS tools since later I need to deploy "the same" plugin on Linux and MAC (but that's another story lets focus on Windows for now).
Challenge:
There is one severe issue I can not resolve reliable with my knowledge/skill level, although I really worked hard in days of researches and tests: Dependency on WINDOWS dll's.
I must assure that this plugin runs on all WINDOWS versions from 7 to 10 (x64 only however).
The shipment of MS redistributables should be avoided since not practical in this case.
Apparently a static linking of the c-runtime library "MSVCRT.dll" seems to be neither allowed by copyright nor a reliable solution since there seam to be many different releases on the various WIN versions. Although Microsoft describes it as "known dll" I'm not sure which version is available where and which version is able to run on a certain Win version. And if a certain MSVCRT.dll runs, does it have enough "functionallity" for my plugin? (To high for me)
The question:
In your professional opinion what's is a reliable way to assure stability for my plugin on WINDOWS 7 to 10 (x64) in terms of Windows dll dependency's?
Are there other pitfalls I should worry about in the context of this dependency's on deployment.
Additional info:
Dependency walker_x64 (what a handy tool!) in this development stage of the plugin shows me dependency's on:
KERNEL32.DLL
MSVCRT.DLL (That's the guy I'm worried the most)
PM_64.DLL (That's the plugin manager of the x64 application)
On my computer (Windows 7 x64), MSVCRT.DLL shows version 7.0.7601.17744, OK, works. But if the customer has, say, a Windows 10 machine, freshly installed (not many MS redistributable versions available), will it work reliably?
I know that similar questions have been discussed before, especially on the c-runtime library "MSVCRT.dll". Many of them before WIN10 however.
The newlib idea (http://sourceware.org/newlib/) for example, 6years ago.
Mingw-w64 ships with archives called: libmsvcrt.a / libmsvcrtXXX.a. Is there a way with those?
I've read all I could find but I have to admit that now I have more doubts and questions than answers...
Your prefessional advice is appreciated. Thank you.
You may rely on presence and stability of at least the following dynamic libraries: kernel32.dll, msvcrt.dll, user32.dll, gdi32.dll. They are system libraries, present in C:\Windows\System32\ folder after the clean OS installation, and created by Microsoft as user API to interact with OS. MinGW library libmsvcrt.a (as well as non-static MS libraries) have no actual processing code but are just wrappers to call these DLLs from system folder.
I haven't been able to find any information on this issue:
I have a C++ Windows Phone 8.1 library project, I would like to convert it into a portable library without having to recreate the project and set all parameters.
I guess it should be possible to do it by editing the vcxproj file, but I don't know how to modify it to make it work.
I meet several issues:
What is the equivalent of Portable Library (C#) for C++?
How to change an existing Windows Phone 8.1 C++ project into this equivalent?
Thanks :)
In general, Windows Phone 8.x doesn't support sharing of binaries with Windows desktop because the import libraries are different between the two (eg, desktop apps link against kernel32.dll but that DLL doesn't exist on Windows Phone). You could share between Windows Phone 8.0 and 8.1 though (provided you only used features available in 8.0).
In theory you might be able to make a static lib that was shared if it didn't depend on any Windows APIs, but it's not really supported. You could try creating a new Static Library project and diffing it against your current project to see what settings have changed.
This changes in Windows 10, where shared binaries are fully supported (obviously you still need ARM vs x86 vs x64 builds depending on CPU architecture).
According to Maximize code reuse between Windows Phone 8 and Windows 8 C++ is not supported as PCL language as this is a .net framework technology.
Note that Portable Class Libraries are a .NET Framework concept and don’t support C++
I also looked into Visual Studio to confirm that and couldn't find a template.
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.
Native exe!
that means my program can run easily without any requirement?
even if I use .net classes?
You know I want to write a program that is so light and I don't like to use C# or any other .net programing language because all of them need .net-framework 4.5.
Just think a 2.5 MB programm needs a +250 MB .netframework.
New Update - 12/01/2016:
It's almost 4 years ago when I asked this question. As you know Dotnet Native is announced. It's an interesting feature which compile IL into native code.
Compiling Apps with .NET Native
.NET Native is a precompilation technology for building and deploying
Windows apps that is included with Visual Studio 2015. It
automatically compiles the release version of apps that are written in
managed code (C# or Visual Basic) and that target the .NET Framework
and Windows 10 to native code. Typically, apps that target the .NET
Framework are compiled to intermediate language (IL). At run time, the
just-in-time (JIT) compiler translates the IL to native code. In
contrast, .NET Native compiles Windows apps directly to native code.
For developers, this means:
Your apps will provide the superior performance of native code.
You can continue to program in C# or Visual Basic.
You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory
management and garbage collection, and exception handling.
Last I checked none of the .NET frameworks were 250+ MB! Yes, the offline installer for .NET Framework 3.5 SP1 is 231MB but it contains x86 and x64 versions of .NET 2, 3 and 3.5 sp1.
You should read this http://www.smallestdotnet.com for details on sizes of various versions of the installers.
Now on to your question:
Yes, It is a little annoying to have your clients install a big framework, even 20-40MB does get annoying. With .NET, the advantage is the ease of programming (In my opionion) compared to other Native options.
Your native options are:
MFC - You need only the VS runtimes installed, which is 1-2MB and is usually installed on newer pcs. Also, you can ship your application with the MFC libraries packaged into a dll which is again <2MB
The trade of here is you need to program in C++, the libraries overall are a very thin layer over the native libraries. and people have had harsh opinions about MFC. I've barely just tried it.
Win32 API - This is going all bare bones, and quite difficult, you could use C or C++ but you'd really have to know a lot about the Win32 API and how windows itself works (Stuff like windows messages, hwnds etc) Its not fun, believe me. But during deployment you would not need any external libraries.
There are tons more options, see here:
Native Windows Application Development Options
https://stackoverflow.com/questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
Here are some links on MFC that might help:
Want to learn Windows Programming,some suggestions?
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
C++ MFC vs .NET?
https://stackoverflow.com/questions/557114/stick-with-mfc-or-go-to-net
you are able to create native exe by using c++ Win 32 projects.
Alas, nearly everything requires a download runtime library and even if you have one installed, you'll need to download updates for them almost continually. Even Microsoft C++ apps nowadays come with security updates that have to be installed if you've compiled your app with them.
But.. there is a solution of sorts. If you use C++, it has a feature where only the things you use are compiled into the final app. Normally, this would require linking with all the library dlls, but if you statically link with the library, you will end up with a single .exe that is as small as can be, and you will not need any dlls (as all the code contained in the library will be compiled into the .exe).
The benefits are debatable compared to dlls, but as MS has pretty much broken the idea of shared dlls in .NET (ie, you practically have to put all the shared dlls in the same directory as your running app, giving you a nightmare in maintenance if you have these shared dlls spread around all your apps) then there's not much of a difference anymore. Static linking is getting a little bit of a comeback and sounds like its what you want.
For modern C++ development, you'll probably want to take a look at Qt instead of MFC. Its a lot nicer to use and is cross-platform so you can run Qt apps on your Android or Linux platforms as well as Windows.