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.
Related
I would like to port a DLL that was compiled for Windows Embedded Compact 7 into a Windows CE 5.0 / 6.0 environment. I'm fairly certain the target assembly language is compatible but from my experimentation it appears that there is something fundamentally different about the DLL's in WEC 7 than in WCE 5. Does anyone know what specifically is different about how the DLL's are compiled in WEC 7 than in WCE 5/6?
I'm assuming the source code for this dll is not available, which could make it difficult to use on earlier versions of Windows CE.
Newer versions of CE have added security features to the CRT library, so if the dll depends on any of those, it would not run on earlier versions.
Besides the target architecture, the OS images would also have to be built using a similar set of OS/SYSGEN features, or, again, the dll might fail to load or run if those dependencies are not satisfied.
The dll could be attempting to dynamically load other dll's, or could be relying on OS behaviour specific to CE 7.0.
In short, a potentially very difficult task without the source code.
A way to get started would be to use the Microsoft dumpbin tool with the /imports option to produce a list of dll's and entrypoints that the dll depends on. Similarly, use dumpbin /exports on the earlier builds of Windows CE that you want to use the dll on, to see what entrypoints are available, and work from there.
Another approach, in case you have access to Platform Builder and are able to generate OS images yourself, would be to use the kernel debugger to examine what happens when the dll is loaded.
Are the dynamic runtime libraries for Visual C++ (more specifically 2008) part of the Windows OS nowadays? I noticed that at least on Windows 8 you no longer need to ship these with your application or have the user install the redistributable package from Microsoft.
Is this true? If so, for what Windows versions and for what versions of Visual C++ does this apply to?
No, they've never been part of the Windows distribution. Deploying them yourself is a hard requirement.
It certainly may seem that they are. Starting with msvcrt.dll in the system32 directory, it has the same name as the C++ runtime dll in Visual Studio versions prior to VS2002 (VS6 and earlier). It is however a private copy of the CRT that is used by Windows executables. And protected by the File System Protection feature in Windows, preventing old installers from destroying the operating system.
It certainly often works by accident. There are many programs that need the Microsoft CRT so it isn't unlikely that the user has run an installer before that got the DLLs installed. Clearly you cannot depend on that common accident.
Similarly for Windows 8, the pre-installed Microsoft.VCLibs.110 package matches the package you need for a Store app written in C++. But that's for the same reason as above, Microsoft Store programs were also built with VS2012, just like yours. What's going to happen in the upcoming VS2013 is a bit muddy right now, we'll know soon.
In my opinion, the answer would be both: Yes and No.
Yes: More recent Windows OS are generally shipped with VC runtimes pre-installed (along with more recent versions of the .NET framework). It is because Microsoft uses the latest/newer Visual Studio before they release VS to the public (or even to MSDN subscribers). If not this way, whenever you install some application (legacy application or some downloaded application), the setup would anyway install the required VC++ runtime. Another way is through automatic updates.
No: In case where none of the above mentioned rules applies. Or, when the VC runtime shipped with a new service pack or a patch. You might have developed your application with newer patch/SP, and that must be installed (as Side-by-Side, of course).
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.
In particular we are developing for Intermec CK30/CK31 running Windows CE. We have an existing C++ project that also targets newer devices (running Windows Mobile 5/6).
The guy who has left this with us, just used to use both environments to develop the one set of source. But I would rather ditch one and develop for all in one environment.
You should be able to use VS2008 for all your development. You'll need to install the platform SDKs for the Intermec and WM versions (WM 4.2 and 5.0 standard should be there by default). VS2010 doesn't yet support Windows Mobile/CE development.
If you are using different environments with different versions of visual studio, you might want to have a look at the cmake builder.
It is a meta-build program, in that it creates a requested build environment (eg. VS2005 or VS2008) for you. You maintain one set of source code and then choose what IDE/compiler to use to build/modify you code. And each developer can choose a different IDE/compiler.
This would be a good compromise, as you are separating your code from your compiler/IDE, and cmake makes it no effort to drop/revive a target compiler/IDE should you wish to later.
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.