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!
Related
So I made a c++ console game. Now I'd like to "release" the game. I want to only give the .exe file and not the code. How do i go about this. I'd like to make sure it will run on all windows devices.
I used the following headers-
iostream
windows.h
MMSystem.h
conio.h
fstream
ctime
string
string.h
*I used namespace std
*i used code::blocks 13.12 with mingw
& I used the following library-
libwinmm.a
Thank you in advance
EDIT
There are many different ways of installing applications. You could go with an installer like Inno or just go with a regular ZIP file. Some programs can even be standalone by packaging all resources within the executable, but this is not an easy option to my knowledge for C++.
I suppose the most basic way is to create different builds for different architectures with static libraries and then find any other DLLs specific to that architecture and bundle it together in one folder. Supporting x86/x86-64/ARM should be enough for most purposes. I do know that LLVM/Clang and GCC should have extensive support for many architectures, and if need be, you should be able to download the source code of the libraries you use and then compile them for each architecture you plan to support as well as the compilation options you need to compile to each one.
A virtual machine can also be helpful for this cross-compilation and compatibility testing.
tldr; Get all the libraries you need in either static or dynamic (DLL) format. Check that they are of the right architecture (x86 programs/code will not run on MIPS and vice versa). Get all your resources. Get a virtual machine, and then test your program on it. Keep testing until all the dependency problems go away.
Note: when I did this, I actually had some compatibility issues with, of all things, MinGW-w64. Just a note; you may need some DLLs from MinGW, or, if you're using Cygwin, of course you need the Cygwin DLL. I don't know much about MSVC, but I would assume that even they have DLLs needed on some level if you decide to support an outdated Windows OS.
I've tried Googleing this but I could not find a solution. I am trying to learn some basic C++. I wrote a simple hello world:
#include <stdio.h>
int main()
{
printf("hello, world\n");
return 0;
}
It compiled perfectly and everything! Great I thought, so I loaded up my virtual machine with XP and no service packs installed, then tried to run it. It told me I needed the MSVCR dll. Is there any way I can completely remove this dependency? I don't want to stuff the program with the dll. I want it to be gone, completely. Is it possible to make and run a program that will run in XP and up? Thanks.
It is technically possible to remove this dependency in C, but I'm not sure it is even possible in C++. And in either case, I would not recommend it. You lose a lot of stuff that the CRT does for you behind the scenes, most of which you don't want to have to reinvent yourself in an inferior fashion. For starters, it's the runtime library that actually calls your main function as well as calling the constructors and destructors for global and static C++ objects.
The best and simplest solution is probably to change how your application links to the runtime libraries. You have two different options: dynamically and statically. Dynamic linking is more memory-efficient and means that your application will take advantage of any bug fixes that are made to the library. It relies on the runtime DLL being present in order for your app to start. Static linking actually embeds the runtime library code into your application during the link phase of the build. This means that you can run without distributing the DLL, but there are important caveats.
For simple apps, it's unlikely that these caveats are relevant. Change the link style in use in your project's options:
Right-click on your project name in the Solution Explorer.
Expand the "C/C++" option in the left-hand treeview, and select the "Code Generation" item.
In the "Runtime Library" property combobox, choose one of the "Multi-threaded" options.
Debug builds should use "Multi-threaded Debug", while Release builds should use "Multi-threaded".
Do note that since you're using VS 2010, you can still choose to dynamically link to the runtime and gain all of the advantages of doing so without having to run the CRT installer on the target machines. All you need is the redistributable DLL(s) placed into the same folder as your application's executable. This makes deploying (and even testing) very simple and straightforward. You'll find these libraries as part of your Visual Studio installation:
\Program Files\Visual Studio x.0\VC\redist\
And of course, the debug versions of the CRT are never redistributable. Since you should not distribute debug versions of your application, this is not a problem. Make sure that you've compiled a "Release" build (using the drop-down combobox in the top toolbar), for which you will require only the redistributable libraries found in the above directory.
Can't I use the runtime that comes with XP?
There is no C runtime for you to use that comes with any version of Windows. Windows itself indeed depends on a C runtime library, but it deploys a private version of that library for its own use. Applications are not intended to link to it or make use of it in any way. You're on your own for deploying all necessary dependencies, and as you've noticed, you cannot assume that the target machines will already have the correct version(s) installed.
You can link the MS runtime statically, Project Options -> C/C++ -> Code Generation -> Multithreaded (or Multithreaded Debug for debugging configuration). No DLL should be needed then.
you can remove the annoying run-time library, do this:
project properties > linker > input > ignore all default libraries> yes
this will give you quiet a few issues you need to deal with, for example, floating
point numbers won't work, stack memory is very small (about 3k), there's no built in help against buffer overflows and such, and you can't use the standard library without copy pasting it in your project.
this will also decrease the size of the .exe nearly equivalent to as if it was hand made
in assembly.
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).
it's been a long while since I've used VS 2010 and C++, and as I'm getting back to using it, I'm running into the same problems that plagued me last year: the exe's that I compile do not run well on older machines that do not have the correct C++ runtimes. I do not even know what link to give them, and I told them to install this after they had an error that said "The program can't start because MSVCR100.dll is missing from your computer. Try Reinstalling the program to fix this problem. Click OK to close the application."). So I went in and set the code generation to /MT and disabled quite a few options, and tried messing around with lots of options, but still the same result.
My question is: Is there a list of complete VS 2010 C++ distributables that I can just give and tell them to install so all of the C++ programs I compile on my VS 2010 will work on Windows XP, or even better, a way to general a standalone exe that contains all it needs to work, and does not rely on DLLs? I'm thinking like linking to a library that has everything the exe references. If it helps, I'm building for both x64 and x86.
P.S. What's up with the manifest file, should I include it or not?
The easiest thing to do is to just install the VC++ Redistributable Package. It has both x86 and x64 versions.
Firstly, before I actually give you the detail:
Warning
If you do this, things will be bad for two reasons:
If there are security or other bugs in the MSVC runtimes, and you take this approach, they're baked into your app which means you need to re-distribute. DLLs are preferred because theoretically people use system update which means any errors get fixed.
Everything else you compile into your exe also needs to do this. If you don't, you end up with two versions of the code and whatever you're using won't link.
One possible solution is to bake the MSVC runtime into your application, by using the cl.exe option (C/C++ compiler settings) /MT which means multi-threaded version of the C/C++ runtime linked statically. As I said, if you try to link against something that is linked itself dynamically to the runtime, you're going to end up in a mess. Also, as I said, this represents an additional security risk factor, so bear that in mind.
The other options are to write an installer that can either download the appropriate runtime, or include the DLL needed.
If you're using some feature of the runtime that exceeds a certain version of Windows (generic statement, but it does happen) then you should be able to use the Windows SDK to target various versions of Windows using appropriate C runtimes.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
google text: visual studio c++ redist
Do not statically link to the runtime; specifically don't do so if you're using any kind of dll for other purposes. It introduces all kinds of bogus problems wrt heap management that you probably don't want to mess with.
Open the properties dialog for your project and select Configuration Properties | C/C++ | Code Generation. The default setting is Multi-threaded DLL. Change that to Multi-threaded and you'll be building and .EXE with the run-time statically linked in. Don't forget to do the same for the debug version.
If you're using MFC or ATL, you will need to navigate to Configuration Properties | General and set "Use of MFC" or "Use of ATL" to link statically as well.
NB: If you link the runtime statically, you must make sure that any other library you're linking in also links it in statically. Otherwise you'll wind up with two copies of the runtime in memory, each with its own heap and bad things will happen when code using one runtime tries to free an object allocated by the other runtime.
This previous answer should hold true for VS2010. I still build with VS2005, but all my apps use the static CRT for the sole reason of being able to run across old and newer machines alike.
I have written some code that makes use of an open source library to do some of the heavy lifting. This work was done in linux, with unit tests and cmake to help with porting it to windows. There is a requirement to have it run on both platforms.
I like Linux and I like cmake and I like that I can get visual studios files automatically generated. As it is now, on windows everything will compile and it will link and it will generate the test executables.
However, to get to this point I had to fight with windows for several days, learning all about manifest files and redistributable packages.
As far as my understanding goes:
With VS 2005, Microsoft created Side By Side dlls. The motivation for this is that before, multiple applications would install different versions of the same dll, causing previously installed and working applications to crash (ie "Dll Hell"). Side by Side dlls fix this, as there is now a "manifest file" appended to each executable/dll that specifies which version should be executed.
This is all well and good. Applications should no longer crash mysteriously. However...
Microsoft seems to release a new set of system dlls with every release of Visual Studios. Also, as I mentioned earlier, I am a developer trying to link to a third party library. Often, these things come distributed as a "precompiled dll". Now, what happens when a precompiled dll compiled with one version of visual studios is linked to an application using another version of visual studios?
From what I have read on the internet, bad stuff happens. Luckily, I never got that far - I kept running into the "MSVCR80.dll not found" problem when running the executable and thus began my foray into this whole manifest issue.
I finally came to the conclusion that the only way to get this to work (besides statically linking everything) is that all third party libraries must be compiled using the same version of Visual Studios - ie don't use precompiled dlls - download the source, build a new dll and use that instead.
Is this in fact true? Did I miss something?
Furthermore, if this seems to be the case, then I can't help but think that Microsoft did this on purpose for nefarious reasons.
Not only does it break all precompiled binaries making it unnecessarily difficult to use precompiled binaries, if you happen to work for a software company that makes use of third party proprietary libraries, then whenever they upgrade to the latest version of visual studios - your company must now do the same thing or the code will no longer run.
As an aside, how does linux avoid this? Although I said I preferred developing on it and I understand the mechanics of linking, I haven't maintained any application long enough to run into this sort of low level shared libraries versioning problem.
Finally, to sum up: Is it possible to use precompiled binaries with this new manifest scheme? If it is, what was my mistake? If it isn't, does Microsoft honestly think this makes application development easier?
Update - A more concise question: How does Linux avoid the use of Manifest files?
All components in your application must share the same runtime. When this is not the case, you run into strange problems like asserting on delete statements.
This is the same on all platforms. It is not something Microsoft invented.
You may get around this 'only one runtime' problem by being aware where the runtimes may bite back.
This is mostly in cases where you allocate memory in one module, and free it in another.
a.dll
dllexport void* createBla() { return malloc( 100 ); }
b.dll
void consumeBla() { void* p = createBla(); free( p ); }
When a.dll and b.dll are linked to different rumtimes, this crashes, because the runtime functions implement their own heap.
You can easily avoid this problem by providing a destroyBla function which must be called to free the memory.
There are several points where you may run into problems with the runtime, but most can be avoided by wrapping these constructs.
For reference :
don't allocate/free memory/objects across module boundaries
don't use complex objects in your dll interface. (e.g. std::string, ...)
don't use elaborate C++ mechanisms across dll boundaries. (typeinfo, C++ exceptions, ...)
...
But this is not a problem with manifests.
A manifest contains the version info of the runtime used by the module and gets embedded into the binary (exe/dll) by the linker. When an application is loaded and its dependencies are to be resolved, the loader looks at the manifest information embedded in the exe file and uses the according version of the runtime dlls from the WinSxS folder. You cannot just copy the runtime or other modules to the WinSxS folder. You have to install the runtime offered by Microsoft. There are MSI packages supplied by Microsoft which can be executed when you install your software on a test/end-user machine.
So install your runtime before using your application, and you won't get a 'missing dependency' error.
(Updated to the "How does Linux avoid the use of Manifest files" question)
What is a manifest file?
Manifest files were introduced to place disambiguation information next to an existing executable/dynamic link library or directly embedded into this file.
This is done by specifying the specific version of dlls which are to be loaded when starting the app/loading dependencies.
(There are several other things you can do with manifest files, e.g. some meta-data may be put here)
Why is this done?
The version is not part of the dll name due to historic reasons. So "comctl32.dll" is named this way in all versions of it. (So the comctl32 under Win2k is different from the one in XP or Vista). To specify which version you really want (and have tested against), you place the version information in the "appname.exe.manifest" file (or embed this file/information).
Why was it done this way?
Many programs installed their dlls into the system32 directory on the systemrootdir. This was done to allow bugfixes to shared libraries to be deployed easily for all dependent applications. And in the days of limited memory, shared libraries reduced the memory footprint when several applications used the same libraries.
This concept was abused by many programmers, when they installed all their dlls into this directory; sometimes overwriting newer versions of shared libraries with older ones. Sometimes libraries changed silently in their behaviour, so that dependent applications crashed.
This lead to the approach of "Distribute all dlls in the application directory".
Why was this bad?
When bugs appeared, all dlls scattered in several directories had to be updated. (gdiplus.dll) In other cases this was not even possible (windows components)
The manifest approach
This approach solves all problems above. You can install the dlls in a central place, where the programmer may not interfere. Here the dlls can be updated (by updating the dll in the WinSxS folder) and the loader loads the 'right' dll. (version matching is done by the dll-loader).
Why doesn't Linux have this mechanic?
I have several guesses. (This is really just guessing ...)
Most things are open-source, so recompiling for a bugfix is a non-issue for the target audience
Because there is only one 'runtime' (the gcc runtime), the problem with runtime sharing/library boundaries does not occur so often
Many components use C at the interface level, where these problems just don't occur if done right
The version of libraries are in most cases embedded in the name of its file.
Most applications are statically bound to their libraries, so no dll-hell may occur.
The GCC runtime was kept very ABI stable so that these problems could not occur.
If a third party DLL will allocate memory and you need to free it, you need the same run-time libraries. If the DLL has allocate and deallocate functions, it can be ok.
It the third party DLL uses std containers, such as vector, etc. you could have issues as the layout of the objects may be completely different.
It is possible to get things to work, but there are some limitations. I've run into both of the problems I've listed above.
If a third party DLL allocates memory that you need to free, then the DLL has broken one of the major rules of shipping precompiled DLL's. Exactly for this reason.
If a DLL ships in binary form only, then it should also ship all of the redistributable components that it is linked against and its entry points should isolate the caller from any potential runtime library version issues, such as different allocators. If they follow those rules then you shouldn't suffer. If they don't then you are either going to have pain and suffering or you need to complain to the third party authors.
I finally came to the conclusion that the only way to get this to work (besides statically linking everything) is that all third party libraries must be compiled using the same version of Visual Studios - ie don't use precompiled dlls - download the source, build a new dll and use that instead.
Alternatively (and the solution we have to use where I work) is that if the third-party libraries that you need to use all are built (or available as built) with the same compiler version, you can "just" use that version. It can be a drag to "have to" use VC6, for example, but if there's a library you must use and its source is not available and that's how it comes, your options are sadly limited otherwise.
...as I understand it. :)
(My line of work is not in Windows although we do battle with DLLs on Windows from a user perspective from time to time, however we do have to use specific versions of compilers and get versions of 3rd-party software that are all built with the same compiler. Thankfully all of the vendors tend to stay fairly up-to-date, since they've been doing this sort of support for many years.)