I am new to programming in C++ on Universal Windows Platform and I have a quick question: I created a project of Static Library (Universal Windows) in Visual Studio 2015 but I couldn't use those Windows Runtime classes such as Windows::UI::Core::CoreWindow in that project.
I guess I need to add include directives or references to libraries but I couldn't find information about that. I tried to search MSDN but just found two pages where two headers were mentioned for namespace default and Collections.
Does anyone know how to reference Windows Runtime classes in a Static Library?
You need to build the project with the /ZW option to allow consuming Windows Runtime Extension in a UWP Static Library:
Right click on the project from Solution Explorer
Click Properties
Select C/C++ -> General
Set the "Consume Windows Runtime Extension" to "Yes(/ZW)"
Click OK
After applying this option, references to Windows Runtime Extensions appear under the references of the project and you can use Windows Runtime Classes.
However, you may see a linker warning while building the library:
Debug\pch.obj : warning LNK4264: archiving object file compiled with
/ZW into a static library; note that when authoring Windows Runtime
types it is not recommended to link with a static library that
contains Windows Runtime metadata if you are using a linker released
before VS 2015 Update 2
I tested the scenario and it worked fine in debug mode, however, I'm not sure if it is the best way since the /ZW option is off by default unlike other types of UWP projects.
MSDN:
You can use a native C++ static library in a UWP project, but there
are some restrictions and limitations to be aware of. Start by reading
this topic about static libraries in C++/CX. You can access the native
code in your static library from your UWP app, but it's not
recommended to create public ref types in such a static library. If
you compile a static library with the /ZW option, the librarian
(actually the linker in disguise) warns:
Maybe you should consider wrapping all the code in a Windows Runtime Component or a UWP DLL instead.
Related
I have an existing third-party static library that I want to use in my project C++WinRT UWP app. Can I do that?
I have read the documentation. But it has me confused.
Documentation talk about "Using a native C++ static library in a UWP App" what is a native c++ library?.
Also, I do not have the source code for this library.
The primary limitation for UWP is that the library:
(a) Must use the subset of Win32 imports that are supported for use in WINAPI_PARTITION_APP
(b) It needs to have been built with VS 2015 Update 3 or later in order to be 'binary compatible' with modern Visual C++ tooling used for UWP.
(c) Some APIs that are used by the static library may not be supported in the "AppContainer" security context (i.e. they may fail in ways the code doesn't handle gracefully).
You should also use /NODEFAULTLIB:kernel32.lib to avoid having your static library force the import of non-supported APIs. The "WindowsApp.lib" umbrella library provides everything that's supported.
More than likely, you'll need the static library built with some modification to actually link successfully and eventually pass WACK.
I have an existing third-party static library that I want to use in my project C++WinRT UWP app. Can I do that? Also, I do not have the source code for this library.
Yes. You don't need the source code to use a library.
You can just use the binary library ( the final output from the source ) that is provided. It can be included as either a static or dynamic library in your final output binary.
How to include that?
Referring to some portion from the doc for your third party static library that may help.
To use a native C++ static library in a UWP project
In the project properties for the UWP project,
choose Configuration Properties > Linker > Input in the left pane.
In the right pane, add the path to the library in the Additional Dependencies property.
For example, for a library in the project that places
its output in <SolutionFolder>\Debug\MyNativeLibrary\MyNativeLibrary.lib,
add the relative path Debug\MyNativeLibrary\MyNativeLibrary.lib.
Add a include statement to reference the header file to your pch.h file (if present),
or in any .cpp file as needed, and start adding code that uses the library.
C++
Copy
#include "..\MyNativeLibrary\MyNativeLibrary.h"
In windows programing,
If you have a static library which is intended to be linked with a dll library where the dll has /SUBSYSTEM:WINDOWS defined, then which of the following marcos should be defined in static library?
_LIB
_WINDOWS
I'm confusing these macros because a static library it self will never show it's own window or console on it's own, so I can't understatnd why do we need to define these macros for static library project?
Just a few points:
It's entirely possible for functions in a static library to create and manipulate UI, either User32 windows or console (I guess Modern UI as well).
Unless you provide special functions for the purpose, the application using your library can't tell what macros were used for library compilation.
Windows headers sometimes will provide defaults if you haven't defined any of a set of macros
(e.g. WINVER)
These macros are only as magic as your code makes them. If you aren't testing them, then defining them is going to have almost no effect.
If your library does conditionally make UI features available, skipping those at compile-time with #if defined(_WINDOWS) has some advantages over run-time enable flags.
In particular, if calls to UI functions are stripped by the preprocessor, the linker won't need to add UI DLLs to the import table. Might make a difference whether your library works on Server Core installs of Windows. At the same time, runtime checks are nice because you only need to compile the library once and distribute one version. Using run-time enable flags and setting the linker to use delay-load might give the best of both worlds.
after fighting with google for houres and various forums and white papers I found out what all that means when using visual studio!
static library:
does not need an /ENTRY or /SUBSYSTEM because the code will be linked into another code.
so the library does not need a console, windnow or entry point
dll:
/SUBSYSTEM should be set to WINDOWS and /ENTRY should not be set, why?
no entry because in visual studio linker automaticaly creates a DllMain entry point.
subsystem of dll should be set to WINDOWS link1 link2
another examle why WINDOWS
exe:
/SUBSYSTEM and /ENTRY should be set explicitly, if not set, linker will again automaticaly set the subsystem AND entry point as noted in the link above.
so to answer my original question, none of the above "stupid" macros must be defined :)
I'm trying to make a binary that can be run on any windows machine without the visual c++ stuff installed (I'm assuming that's what MSVCP120D.dll is however my searching was not very fruitful as to what this actually is). I made a game for an assignment and wanted to have other people (non-devs without VS stuff installed), help me test it but they kept getting errors saying that the above dll is missing. I'm not using any Visual C++ stuff and have the /Za flag set to ensure that it's just ANSI C++. Does Visual Studio support compiling ANSI C++ and if so how do I go about making it not use Visual C++ stuff, if it doesn't support this what compiler should I use?
As you can see here, the MSVCP DLL is the platform's implementation of the C++ Standard Library. In short what that means is you cannot distribute your application without needing the "stuff" that these libraries provide. All compilers regardless of platform would need some kind of implementation of the Standard Library. Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is built in to your program directly, rather than being shipped in a separate DLL. In order to do this, you must statically link your application to the Standard Library.
There are a few ways to accomplish this. One way is in Project Settings. In "Project" > "Configuration Properties" > "C/C++ Code Generation" > "Runtime Library", choose "Multithreaded (/MT)" as opposed to "Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means "Debug." This means that you are trying to distribute a debug build of your program. You should (almost) never do this. Distribute release builds instead.
You have three options (in the order I'd recommend):
Don't statically link, instead get people that want to run your game install the visual studio re-distributable package. 32-bit VC 2010 version here: http://www.microsoft.com/en-us/download/details.aspx?id=5555
Statically link the CRT (the dll you don't want to require at runtime) see here for details: How do I make a fully statically linked .exe with Visual Studio Express 2005?
Build an app that doesn't even use the CRT at all. Here you will have to implement your own operator new that calls HeapAlloc(), and operator delete that calls HeapFree(), its an interesting challenge ;). To do this you tell the linker to ignore all default libs.
Build with the static runtime libraries rather than the DLL versions.
Go to Properties, C/C++, Code Generation, Runtime Library and select /MTd or /MT rather than the /MDd and /MD options.
Configure your project to link against the runtime statically rather than dynamically.
First of all the D on the end of the name indicated a debug build. If you make a release build then it will need it without the D. This is important because microsoft do not allow the debug libraries to be distributed without visual studio.
The machine you are trying to run the program on may already have the release runtime installed as lots of programs use it. If not then install http://www.microsoft.com/en-us/download/details.aspx?id=30679 on the machine ( I think that's the right one but can't check at the moment)
You'll want static linking, that 'builds in' the external library calls into your binary. It does have the added affect of larger binary file, but in your case that doesn't sound like that big of a deal.
On a side note, MSVCP120D.dll is the Microsoft Visual C++ 12 debug DLL (dynamic link library) that contains all of debug C++ libaries (i.e. iostream, string, etc). That library is what you would be 'baking in' to your final binary.
Hope that helps.
I encountered this error when I tried to execute my exe on a different machine that had a newer version of Visual Studio on it. You need to change the project properties and re compile in order for this to go away.
To do this:
Open up solution that you are trying to run
Right click on the Project file - > Properties
In Configuration Properties and General, Ensure Platform Toolset is configured to be the correct compiler on your machine. If it is not correct, it should give a message next to it saying that it's not installed.
Build and run the code again and you should no longer get the issue.
I am building a C++ dll that will be consumed by C & C++ applications. I understand that /MT will cause the static library (LIBCPMT.LIB) code to be dumped into my dll, hence no dependency.
/MD will link to import library and will have a dependency on the C++ runtime (MSVCP100.dll).
My doubts:
In /MD option do I have to make sure the right version of the C++ runtime dll, the one's import library I had linked to during development, exists on Windows OS?
Do I need to care about what C/C++ runtime the applications using my dll were linked to ? I want to use the C++11 features but want to make sure old C++ applications can still consume my dll.
I am planning to use VS 2012 RC now and I think their C++ runtime libraries got updated. Will there be any dependency again on what version of Windows that code will execute on or what libraries the applications consuming my dll used?
yes, the relevant runtime library DLL(s) must be present
yes, client code generally needs to use the same runtime. however you can work around that by offering only a C style interface, or a COM interface, to clients. e.g., no std::string or other data that contains things allocated by the runtime.
yes, you'll be limited to the supported target platforms for VS 2012—Windows Vista and later.
My code does not use MFC. However, when I built my static lib the party that is trying to use it is stating that they are having a hard time because my code lib has the following dependencies in it:
mfc80.dll and msvcr80.dll
Is there a way to remove those and rebuild? I am using vs2008.
A static library by default links to the dynamic runtime, which is why your code has a dependency on msvcr80.dll. Visual C++ programs must link to a runtime. You can change your static library to use a static runtime to remove the dependency. This is done in the Configuration Properties | C/C++ | Code Generation | Runtime Library setting. However, the chosen runtime library must match what is used in the project that links your static library.
Your code probably depends on mfc80.dll because you have Configuration Properties | General | Use of MFC set to one of the MFC options.
In my opinion, Visual C++ (and Windows in general) was made for dynamic libraries and dynamic runtimes. Static libraries seem like more of a hack, in that they have a surprising number of limitations, pitfalls and idiosyncratic behavior. Better become familiar with producing and consuming dynamic libraries -- it's better in the long run.
mscvr80.dll is the release CRT. You can remove this dependency by setting the compiler to statically link. Most likely, you're trying to load MFC because the project is set to use MFC, even though you're not using it. You can remove this in the project settings.
Although, gotta question why VS2008 would produce mfc80.dll and mscvr80.dll dependencies, instead of mfc90.dll and mscvr90.dll.