Well, trying to build a simple exe in visual studio 2012, with c++ win32 console app, just with a
printf("-----");
After build the release version, its running ok.
When transfer to another windows 7 clean installation, at running i get notice that the MSVCP110.DLL is missing...
Its not a native app ??? why extern dll is needed ?
In old win95 I make many executables with visual C 6 and its run standalone withou any dll.
I will always deplay this dll's with the "native" exe ?
When you write a C++ program, you use a few low-level libraries to interface with the machine. The C++ Standard Library is one example. Consider for example, new. When you call new in your program, you're invoking a piece of code that implements that functionality. Where is that actual code?
It's in a library. That library is deployed in a few different ways. One way is through dynamic linking, where the library is in the form of a DLL that needs to be present on the machine where you run your program. That's what MSVCP110.DLL is -- it's one of the library files your program was compiled against. Another way is to use static linking, where the code from that library is compiled directly in to your program. This results in a signifigant increase in the size of your application, but the other side of that coin is you don't need those library files to be on your target machine. You also need to make sure that other libraries your program use are also built against the same static library. If your program shares data with other programs, you further may need to ensure that those programs use the same static libraries.
Microsoft and Windows aren't unique in this. The same thing happens under Linux, albeit the libraries have different names.
There are pros and cons to using either shared libraries (eg dynamic linking) or static libraries. It's simple and catchy to say "gahrrr I hate shared libraries" but unless you understand why either is appropriate in what situation you stand to deploy a poorly-designed program.
Related
This is a possible duplicate to this question but the answer is not solving my problem...
I want to use third party software delivered by c++ headers, libraries (.lib) and dlls for a project. Because it will run on a BeagleBone, I am writing this project for Linux. Is there any proper way to link dlls for Linux applications?
Highly unlikely to ever work:
Windows uses a different file-format for executable files (and DLL's are essentially executable files - same for shared libraries in Linux). This means that relocation information and symbol linkage is different.
Even if you manage to load and relocate the DLL, you most likely will need many other DLL's (such as the compiler runtime and system runtime [kernel32.dll for example]) to actually run the application. And of course, those dependent files need to have a correct interface to work on Linux (see #3)
There's nothing stopping a Windows DLL from making system calls directly in the shared library - these won't work in Linux.
Your best choices are:
Request Linux versions from the supplier of those libraries. Depending on what the functionality is, it may or may not be an easy task for the supplier to produce alternatives for different architectures.
Run the application inside the WINE (WINdows Emulator) package.
Run a Windows virtual machine, and run the application inside that.
Write your own replacement libraries, or find others already available out there.
There is this library which is used as a reference by other programs: https://github.com/RetroAchievements/RASuite/tree/master/RA_Integration
I have downloaded the compiled programs (that come with the compiled library) and they work fine. My goal is to make a change in the library code, re-compile it and replace the DLL of the compiled programs I have downloaded with my own compiled DLL. Like so:
ProgramA.exe
|_ RA_Integration.dll < replace with my own (built)
Before even changing the code, I am just trying to compile the DLL and use it along the compiled programs I have downloaded. I am not willing to re-compile the programs themselves because it will be too much work because of dependencies etc. And I also would like to be able to just "ship" the DLL to whoever wants my fix.
So I have downloaded the source code of that library, re-compiled it myself successfully but when I use it instead of the one that comes with the programs, they do not start up (Windows Event Viewer say that there was a problem loading my DLL).
I am assuming that my system have differences with the system that built the original DLL and that it is the reason why it fails. My question is: can I find those differences? Although I am a professional .NET programmer (as in it's my job) I am a C++ newbie and I am having trouble to understand all those linker/precompiler/dependencies/c++ stuff that seem to give different builds/results from a machine to another.
All I have been able to find is that in the project properties the "Platform Toolset" is "Visual Studio 2013 - Windows XP (v120_xp)", therefore I have installed Visual Studio 2013 (with Update 5 since it seems Windows XP support was not present in base VS2013) but that seems to not be enough. I am running Windows 10, which was surely not the OS the original programmer used when they compiled the DLL a couple years ago, but not sure if that matters?
Is there anything that could be found from the DLL itself or from the project that would hint me as to what I need on my system?
Hope that makes sense.
Thanks
Before even changing the code, I am just trying to compile the DLL and use it along the compiled programs I have downloaded. I am not willing to re-compile the programs themselves because it will be too much work because of dependencies etc. And I also would like to be able to just "ship" the DLL to whoever wants my fix.
Here's your fallacy: your DLL is a linking dependency. You must re-build your application, because obviously, the ABI of the library changed, rendering it incompatible with what your program tries to call in functionality that it expects to be in the DLL.
There's no way around that short of building an ABI-compatible wrapper DLL using your precious programming knowledge :) Finding these differences is hard – because, you could for example export a symbol list from your DLL, which will basically contain all the functions that DLL "offers", but some aspects of how these functions need to be called aren't actually part of that and can only be deducted by a linker (or a skilled person with too much time on their hand and an unhealthy obsession for parsing things in their head) from the C++ source code.
In other words: you changed what you're run-time linking your program against. You must now rebuild your program. End of options!
I'm working on an application that needs to be compatible up to Windows XP (yea... I know...), my colleagues are arguing that they don't want to use std::string because it might load some dlls that might change the code behavior.
I'm not sure either if they are right or wrong here. At some point, there has to be some common grounds where the application can be loaded.
And so given the context where an application have to be self contained as much as possible, would this application be required to load a dll in order to use the stl or string or else coming from the standard libraries?
Also, assuming I use the -static-libstdc++ flag, by which order of magnitude will the executable be bigger?
In windows, STL is supported using CRT libraries. These libraries require the run time DLLs to be deployed before you running the application. Compiling code with different version of visual studio will create dependency on a particular version of CRT. Compiling code with vs2013 will need a version of CRT much different than the vs2010. So you cannot use/pass STL objects from one version of CRT to another dll consuming a different version. Please go through microsoft articles before consuming the CRT libraries. Below article is for vs2013:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
I would suggest you to use ATL:CString which is much easier to implement & the static version library also much compact than CRT libraries.
When i create a new project an alert box opens up asking
Multi-threaded Dynamic CRT mode
or
Multi-threaded Static CRT mode
what's the difference ??
And Explain..
Dynamic: Dynamically link the runtime, which means your compiled files will be smaller, but require the Microsoft Visual C++ Runtime files to be installed. Depending on the Windows versions of the target system as well as other programs being installed there (and the version of VS you're using) it's likely that these are already installed, but you can never be sure, so you'll at least have to provide a download link in case your program doesn't run.
Static: Statically link the runtime, which means parts used are included in your compiled files. This will result in slightly larger files (depends on how many parts of the CRT you're using) and your code might be slightly faster. You won't need the runtime files to be present on the target system.
Which one to choose? Up to you.
If you're providing an installer that will take core of dependencies (like the CRT), using the dynamic version might be the better choice, especially when you're using multiple binary files (like executables and libraries). Otherwise you might essentially end up with duplicated code.
For a better "unzip and run" experience, I'd prefer using the static runtime.
You could as well use the dynamic runtime and provide a small "bootstrap" program, linked with the static runtime and checking whether the runtime is properly installed. If it isn't, it would download and install it prior to running the actual program.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
You cannot code a program in C++ that would work on any computer without giving your source code to be compiled.
For example, you could perhaps code in C++ a program, and compile it and build an executable which works on Windows x86-64, but that executable won't work on Linux (or MacOSX), and it won't work on ARM (e.g. Android phones) unless you consider using emulators
If you are developing your code with Visual C++ you may need to consider two options:
Make sure you link all libraries statically.
Install on the target computers along with your program Microsoft Visual C++ Redistributable Package corresponding to the Visual C++ version you use like the one at http://www.microsoft.com/download/en/details.aspx?id=5555. Some installer generating software will make it for you automatically.
Normally you would link your object file with some sort of a platform dependent loader. This loader loads your object and does all the stuff to start it from memory. Normally you can tell your compiler to link your object file and compile a blob. OpenGL is a powerful API and is usually distributed as a.dynamic linked library and is linked at runtime to your program. If I remember you just have to make sure the dll is where you want it and load the dll in your program from start.
Your C++ program is compiled and linked into an executable before it is run. You should be able to find that executable in a Debug or Release subfolder of the folder containing your project.
OpenGL, if you're not using GLUT or similar libraries, should just come with Windows and pose no additional problems. If you do use GLUT, it's enough to bundle the .dll file with your application.
In any case, the source code won't be necessary.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
By compiling and linking it into an executable. As long as you're not using some interpreted language (like Python, Ruby or such) you're presented with an executable inevitably. The biggest problem you may/will run into is dependencies on libraries. However those are linked into a binary as well. So what you're going to ship will be just a .exe; and some .dll maybe. Usually you'd wrap this in a installer package for deployment to the end user. Installers are created with something like the "NullSoft Installer System" (NSIS).
OpenGL itself is just a API, provided by a system library. So you don't ship OpenGL with your program, but expect the user to have it installed on the system (which will be the case if he installed the graphics drivers).