I'm going to be working with a C++ library written in plain C++ (not .NET and without MFC). The library is available compiled using both Visual Studio 2005 / Intel Fortran 9.1 and VS 2008 / Intel Fortran 10.1.
Obviously I'm going to grab the binaries for VS 2008 since that's the environment on my computer but I'm curious if there are reasons why a straight C++ library wouldn't be compatible between VS 2005 and 2008. I'd assume that the name-mangling would be the same but maybe there are other reasons. I haven't used C++ in a long time so I'm a little rusty when it comes to these things.
It should probably work. The DLL compiled with VS 2005 will be dependent on VS 2005's implementation of the C standard library (msvcr80.dll), whereas your code will depend on VS 2008's C library (msvcr90.dll). This means that at runtime, both versions of the C libraries will be loaded, which is ok, but it increases your memory usage and slows down your load time by a very small amount.
As the other posters have commented, you should be able to work in this way.
However, there is one issue that can be a big one - memory management. The C++ runtimes, in particular, can be tricky.
The biggest issue is that there are some incompatibilities between how the 2005 and 2008 runtimes manage memory. Everything works fine, provided you always allocate your memory in your VS2008 DLL, and always delete the memory allocated from within there within your DLL. This usually requires making some "extra" factory and cleanup methods in your DLL, and exposing these.
If you allocate memory from within your VS 2008 DLL, then delete it from code compiled using VS 2005, or vice versa, you may run into some very difficult to debug problems. It will often work, but have random crashes or instabilities.
The biggest issue you will run into is the usage of the CRT. If the CRT (C RunTime) is statically linked into the DLL, you shouldn't have any issues.
However if the CRT is dynamically linked into the project you may run into trouble. Visual Studio 2005 and 2008 use different versions of the CRT and they cannot easily be loaded togeter. But if one or both of the DLL's statically links the CRT you should be in decent shape.
Related
I have created a c++ game with the following libraries : SDL2 and SDL2_MIXER. I want to give the game to some friends who have no programming experience to play with. Now I don't really know how to do that.
What I have tried is to use installshield limited edition with visual studio. After giving the installation program to some friends they all had a common problem-error that a dll MVCsomething was missing.
What is the simplest way to give my friends the app? Since c++ is translated to assembly do I have to compile the source again each time I change a machine?
Given the way that you've tagged your question, it is unclear if you are using Visual Studio or CodeBlocks to compile the code.
I guessing that you're compiling it in Visual Studio, and therefore they're getting an error that they don't have the appropriate MSVCRT DLLs—in other words, the C runtime library that your code depends upon, having been compiled with Microsoft's compiler. Point them to download the version of the Visual C++ Redistributable matching the version of Visual Studio that you're using on your development computer. For example, if you have VS 2015, they'll need to install Visual C++ Redistributable for Visual Studio 2015.
Alternatively, you can bundle the required redistributable into your installer to make sure that it gets installed automatically, if it isn't already. In InstallShield, I believe that's done by marking the VC++ Redistributable as a "requirement". Make sure that it's set as a prerequisite. Although, judging from the answer to this question, it may be that InstallShield LE doesn't support this. If that's the case, my advice would be to ditch InstallShield altogether and use something like Inno Setup to build an installer. There is a moderate learning curve, but it is useful knowledge. That being said, I can't believe Microsoft would ship a mechanism for creating a setup program with Visual Studio that didn't support automated installation of the CRT. I have not kept up with what Visual Studio supports nowadays with respect to setup wizards.
Since c++ is translated to assembly do I have to compile the source again each time I change a machine?
No, no. Assuming that your friends are all running Windows (and not, say, Linux) and have x86-based machines (which they do if they're running Windows), your code will work fine. The only hitch would be if you are compiling 64-bit code that runs on your machine, but they only have 32-bit machines. Then you'll need to have a 32-bit and 64-bit version. (Or a single 32-bit version, which will run on both.)
I have a C++ DLL. We developed it originally in Visual Studio 2005 and recently upgraded it to Visual Studio 2013. This DLL then calls into a Fortran DLL for some functionality (the Fortran DLL is provided by a third party developer who cannot share source code). Recently, for some inputs, the call to the Fortran library has started throwing an exception:
First-chance exception at 0x1C00BA50 in Application.exe: 0xC0000005: Access violation executing location 0x1C00BA50.
This exception only occurs when the Fortran DLL is called from the Visual Studio 2013 generated executable on Windows 7. When I call the same Fortran DLL with the same input from the Visual Studio 2005 executable, there is no exception and the Fortran DLL produces correct results. Additionally, running the Visual Studio 2005 solution on Windows XP SP3 does not produce an error either.
Supporting details:
The C++ DLL that calls the Fortran is a 32-bit, x86 DLL
Fortran DLL is built against DFort 6.1a
In dependency walker, needs: DFORRT.DLL, MSVCRT.DLL, and KERNEL32.DLL
The C++ executable is built for x86 using the "Visual Studio 2013 - Windows XP (v120_xp)" Platform Toolset
The crash does not happen on Windows XP SP3; it does on both 32 and 64-bit Windows 7 machines. I am setting up a Vista environment to test there, but won't have results for a few days.
If it helps, the function signature is:
extern "C"
{
typedef long (__stdcall *FUNCTIONID)
(
float* array1,
float* array2,
float* array3,
long& numItems,
long& numThings,
float* thingData,
float* thing2data,
float& result,
long* resArray,
float* resArray2,
float* resArray3);
}
The library is loaded by:
m_funcDLL = ::LoadLibrary("DLLNAME.DLL");
Additionally, we call this by:
FUNCTIONID pfnFUNC = nullptr;
pfnFUNC = (FUNCTIONID)GetProcAddress(m_funcDLL, "FUNCNAME");
if(pfnFUNC) {
try {
iErr = (*pfnFUNC)( args...);
}
}
The args are a mix of static arrays and dynamic arrays (although we have experimented with C++11's std::array and std::vector to pass things around; we get the same error using both container types).
We're not using Unicode on our builds (that's a wishlist item for now), so we're using Multibyte Character Sets (although none of the arrays passed in are char arrays).
The primary question I have is: Is anyone aware of any binary compatibility issues with Visual Studio 2013 on Windows 7 that would cause crashes like this? Are there things I should be looking at that I'm not?
DLLs and code using DLLs which are linked against different versions of the runtime library (and possibly other libraries) are in danger of breaking, if one or more of the following happens:
Interface to DLL uses classes/structures, where the size might differ depending on version of runtime library. (One unfortunate member might be enough).
Heap objects are not being allocated/freed at the same side of the interface.
Sometimes people play with compiler settings regarding alignment. Maybe different versions of compilers also change their "policy".
Look out for #pragma (pack,..), __declspec(align()) etc.
In older Versions of VS there were "single threaded" and "multi-threaded" versions of run time libraries. Mixing DLLs and Applications not linked against the same kind of library could cause trouble.
#include <seeminglyharmlessheader.h> in header files, seen by both application and DLL can hold some nasty surprises in stock.
Maybe an (unnoticed) change in other compiler/linker settings, e.g. regarding exception handling.
I could not fully follow the 32bit/64bit things you said in the question part. I don't think, mixing both works, but I also think you are not trying that.
I am trying to run a program I compiled in Visual Studio 2013. However, I get the error
The program can't start because MSVCP110D.dll is missing from
your computer. Try reinstalling the program to fix this problem.
This is not a very helpful error. However, after some Googling, I found that it is (apparently) trying to load a standard c++ library dynamically, and that to get around this I need to specify the /MT option rather than the /MD option. This leaves me with a number of questions:
What exactly is that doing?
What are the benefits of /MD as opposed to /MT? I mean, there must be a reason that it is the default options...
How would I go about getting the looked for .dll and getting Visual Studio to use it? I downloaded this, but honestly don't know exactly how to use it.
Most importantly, how to I get that error to go away and my program to run?
Some additional info: I am compiling in Release mode using an x64 build.
The problem is that you are mixing different versions of Visual Studio by using Qt that was compiled using a different compiler. Remember that each version of Visual Studio will have its own runtime/CRT. The Qt dlls that were compiled with Visual Studio 2012 and will be dependent on the Visual Studio 2012 runtime. They will not use the 2013 runtime.
The solution to this problem is to recompile all of your code and dependent libraries/dlls with the same compiler.
Warning:
Some users will try to just install the dynamic runtime (or recompile dependent libraries with static CRT) from the other version of Visual Studio however this is not a solution to this problem mainly because each runtime has its own independent heap. Having separate heaps can and will lead to random crashes caused by allocating memory in one heap and then trying to free it in a different heap. Since the heaps do not share information about allocations or deallocations this leads to having corrupt heaps. From my experience the problem does not always cause an instant crash. The crash may or may not happen on the next allocation of the corrupt heap so debugging this situation can be very frustrating.
Is it possible to develop in C/C++ for windows and not to link against the msvcr100.dll?
I understand that this is the standard c library for windows, but I was wondering how all the programs on my computer could run if I hadn't Visual Studio or the Redistributable package installed?
Right-click your project in the Solution Explorer window, Properties, C/C++, Code Generation, Runtime Library setting. Change it to /MTd. Repeat for the Release configuration, pick /MT
You will now link the static version of the CRT, any functions you use get directly linked into your EXE instead of getting them from msvcr100.dll at runtime. So you no longer have the requirement to deploy the DLL along with your program.
Avoid using this option if you create your own DLLs. It then gets to be important that those DLLs and the EXE use the exact same CRT so they'll all share the same CRT state and the same heap. Because if they don't then you'll have nasty problems with passing C++ objects or pointers that need to be released from one chunk of code to another. An AccessViolation if you are lucky, a memory leak if you are not.
If you restrict your project to use only C programming language/library, then you can
only link against MSVCRT.lib which is completely baked in any Windows version since Windows XP SP3.
It means, that rather than dependency on MSVCR100.DLL (or any other Visual Studio DLL), you can only link against the standard C functions in MSVCRT. By the way, this technique is used in CoApp project developed under umbrella of Microsoft, so I'd consider it as a good pratice in such cases as yours.
Simply, download Windows DDK and link only against $(DDKInstallPath)lib\Crt\$(DDKPlatform)\msvcrt.lib
On Windows, I doubt it's possible to create a non-trivial program that doesn't use the CRT in some way.
It is possile to use the CRT without linking to msvcrXXX.dll -- simply link to the static libs instead. But to address your question:
how all the programs on my computer could run if I hadn't Visual
Studio or the Redistributable package installed?
If the programs on your PC were linked to msvcrtxxx.dll, then they couldn't. Sinmply, the redist that a particular program needed was already installed on your PC before you even came along, probably. Or at least, the parts of the redist needed by the program.
I have a DLL that gets loaded in my application, like so:
procedure LoadTessDLL;
var
DLLHandle: THandle;
begin
DLLHandle := LoadLibrary(PChar(ExtractFilePath(application.exename) + 'tessdll.dll'));
if DLLHandle >= 32 then
begin
TessDLLLoaded := True;
We discovered that on an XP PC with Service Pack 2, the DLL fails to get loaded (the DLLHAndle = 0 etc), UNLESS we install Microsoft Visual C++ 2008 Redistributable. Then it gets loaded and works just fine.
Please can you help me get this working without it?
Do you control the source DLL? If not then no, the DLL relies on the C++ 2008 Runtime and it must be installed for the DLL to run and you need to add that as part of your install.
If you you do control the source for the DLL then statically link it to the C++ runtime, which will build the runtime into the DLL.
This issue has nothing to do with Windows XP. The DLL requires the C++ 2008 runtime on Vista and 7 as well, it just so happens that the machines you tested with already had it installed. The C++ runtime is not guaranteed to be installed on an any version of Windows.
If the DLL needs the VS2008 redistributable then it needs it and you should include the redistributable as part of your product's installer.
Microsoft provide the redistributable packaged up for inclusion in other installers and it is intended to be used in this way. (It'll add a megabyte or two to your installer.)
There is no getting around this unless you have the source to the DLL and can recompile it to statically link the C Runtime.
(Even if you do have the source, simply recompiling with static linking may introduce bugs. It's possible the DLL assumes it shares the same heap as some other module(s) in the process and that's only the case if they all dynamically link to the same C Runtime DLL. Well designed DLLs avoid such assumptions but you'd need to double-check the way the DLL is written to be sure.)
Well, my best guess would be that your TessDLL.DLL requires a DLL from the Visual C++ distributable. If it can't find the given DLL, it fails to load.
If I am right on this, the only way it will work without it is if you have the source code to TessDLL.DLL and remove all dependencies on Visual C++'s DLL.
A good place to start debugging this is on a station where it actually works. Make a little test program that load the DLL. Run it in the debugger and see what other DLL gets loaded when you load your DLL. If you're lucky, the probem could be in the version of an OS file that the MSVC redistributable happens to update.
Prior to installing Visual C++, I assume you have the DLL some place on your computer and installing VC puts another copy of the DLL possibly in your environment's PATH.
Have you tried putting the tessdll.dll in a location that is included in your search PATH? Say System32 or in the same directory from which you're running your executable? I'm not familiar with Delphi so I'm guessing at the logic of ExtractFilePath
"tessdll.dll". isn't that a DLL that's part of the Tesseract OCR software? The Windows version is compiled with Visual C++ 6 and thus it needs those runtime libraries. Your version seems to be compiled with VC++ 2008.
If you have the RAD Studio version then you could download the code and recompile it all with C++Builder, although that might need some adjustments. More information about the code also seems to be available here.
You have this options:
Compile the DLL without requiring the runtime, but be aware of issues if you have multiple DLLs written with VC++2008 requiring a shared runtime
Install the VC++ 2008 redistributable, which will install a system-wide available runtime
Install the needed VC+2008 runtime DLLs in the same path as the DLL requiring it, thus having a "private" copy of that.
See here: http://msdn.microsoft.com/en-us/library/zebw5zk9(VS.90).aspx