How can I use DLLs and libraries compiled with Visual Studio 2008 from within a Visual Studio 2003 project?
Thanks,
Dan
You can definitely use a DLL. I used the same third-party DLLs in VS2003 and VS2008. To make things a lot easier, you should only pass plain old data types to and from the DLL functions. Structs or classes is much more difficult, but should also be possible in most cases between VS2003 and VS2008.
Check out this questions for far more in-depth info than I can give you.
In general, it's unlikely that you'll be able to use compiled C++ libraries (dynamic or static) with another compiler unless one of the compilers is explicitly listed as binary compatible with the other.
Some answers have mentioned 'third party' or Windows DLLs. However, I'd be willing to bet that most, if not all, of those DLLs were using C APIs, and not C++. The C++ ABI (Application Binary Interface) is not standardized - things like name mangling are not guaranteed to be identical across different versions of the same compiler, and calling conventions can vary based on compiler options.
A quick Google search didn't turn up any links that looked usable, but as I said in the beginning, in general, you cannot use a compiled C++ library, static or dynamic, in code compiled with a different compiler. C is a different beast, and that answer is completely different!
You cannot do that. The only possible thing will be to recompile to target .NET 1.x.
Related
I'm writing a simple C++ application in Visual Studio. It also has a setup project.
It works well on my development machine, but when I'm installing this application on user's machine it requires Visual C++ Redistributable Package. I'm wondering why does my application require C++ Redistributable? Standard C++ runtime library is shipped with Windows, isn't it?
The only version of the C runtime library which is shipped by Microsoft with most of 32 bit Windows versions is msvcrt.dll. This library provides a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc.
Visual Studio 6.0's compiler links against this library, so if you are developing in VS 6.0 you shouldn't encounter any problems on most users' machines.
However, if you are developing in VS 2005, VS 2008, VS 2010, VS 2012, VS 2013 or VS 2015, you have to distribute additional C runtime libraries along with your application. This is because their compilers link against msvcrt80.dll, msvcrt90.dll, msvcrt100.dll, msvcrt110.dll, msvcrt120.dll and msvcrt140.dll respectively, which are not shipped with Windows.
Solutions:
Possible solution is to link statically with runtime library, but it may cause a lot of problems in case you have both .exe and .dll in your application. Don't do that.
To be more specific, I'll allow myself to quote a part of this answer:
Using /MT is risky if you create DLLs as well as an EXE. You'll end up
with multiple copies of the CRT in your program. This was especially a
problem with earlier versions of VS where each CRT would get its own
heap, not so much with VS2012. But you can still have ugly runtime
problems when you have more than one "errno" variable for example.
Using /MD is highly recommended to avoid such lossage.
Another possible solution is to require an appropriate Microsoft Visual C++ Redistributable package to be installed on the user's machine.
It may be done by specifying this requirement in prerequisites property in your setup project.
Also, you can distribute the runtime dll by including in your setup project the appropriate "merge module". In this case don't forget to add the appropriate "policy merge module" to avoid errors caused by incorrect runtime version.
Finally, you can just put required DLLs in the same folder in which your application is installed.
Further reading:
"Redistributing Visual C++ Files" - Official MSDN documentation
Even though some comments said that «link statically with runtime library, but it may cause a lot of problems when you have both .exe and .dll in your application.» this is NOT TRUE. First we DON'T statically link DLLs! We statically link OBJs and LIBs. LIBs are static libraries; DLLs are dynamic libraries, and you may choose to use LIBs (static) or DLLs (dynamic). It's entirely up to you to choose. The ONLY drawback (for the DLL fans) is that if you want to update one library, you need to compile and link again. I personally deploy ALL my software static linked and because of that I earn the bonus of don't even need installers. The software I develop is 100% portable (a feature that in the pre-installer era was general procedure), and the final user is free to simple COPY from one folder to another or even from the hard drive to flash drive (or vice-versa). The error message «DLL not found.» simply doesn't exist ... NEVER.
Some folks think of statically linking as toy software: WRONG! I can write a full featured application that connects to a DBMS (Oracle, SQL Server, ...) or any other kind of application.
I have a DLL generated from Visual Studio 2010, but I need to link it to a 2008 project that needs to remain 2008 for various other reasons. Anyone run into similar trouble or have advice?
VS2010 is .NET 4.0
VS2008 is .NET 3.5
So the answer for your question is NO because if the dll is making use of any of the specific .NET 4 features, it wont get executed in your 3.5 environment. Also it may happen that the assembly mapping is different in both the .NET version and that may become one of the reason for the 4.0 dll not getting executed in 3.5 env.
I am not sure, but you may look at COM Interop features. May be it can help you in achieving what you want. But it would be too messy !!
Dynamic-Link libraries (DLL) are an integrated part of the Windows platform from its very beginning. DLLs allow encapsulation of a piece of functionality in a standalone module with an explicit list of C functions that are available for external users. In 1980’s, when Windows DLLs were introduced to the world, the only viable option to speak to broad development audience was C language. So, naturally, Windows DLLs exposed their functionality as C functions and data. Internally, a DLL may be implemented in any language, but in order to be used from other languages and environments, a DLL interface should fall back to the lowest common denominator – the C language.
http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
Standardized C style interface, should be ok, though that pertains only to non managed C++.
The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)
Can we 'easily' (in some way) compile C++Builder project into VisualStudio 2005 C++. New in C++ i'm looking for references in that matter (CBuilder vs VS). Thanks.
Well, not really. It's true that the "pure" C++ parts should compile, you have two very big gotchas to deal with:
First, Borland made some proprietary extensions to C++ to make it compatible with their Delphi products. I don't remember what these are offhand, but they could be a problem depending on what you're doing.
But the main problem is the VCL, the main GUI library. If you're developing in C++Builder, then 99% of the time you're using the VCL, and using it rather heavily. AFAIK, the VCL will not compile under any Microsoft compiler for many reasons, including the one I already mentioned.
So basically, you're stuck porting to .NET ( or MFC or whatever if you're a masochist) if you want to get this running under VisualStudio. One bright spot here is that many 3rd party component developers have embraced .NET, so you may not have to do as much work to port the project as you think.
If you use the VCL classes you won't be able to compile your code in Visual C++. The VCL introduces some new language structures to the C++ language, to make it compatible with delphi, __property etc. And even if you can move the VCL code to some external dynamically linked library there will still be a lot of problems calling the VCL functions. This is because the Borland __fastcall calling convention differs from most other compiler implementations of it. The Borland version passes 3 arguments to registers, while most other compilers use 2.
All in all there can occur a lot of problems from different compiler implementation, in particular if you use the VCL or the __fastcall calling convention. The thing about C++ Builder is that it is build to be compatible with Delphi and the VCL, and while the VCL is an excellent framework for RAD and GUI programs, it adds the cost of less compatibility with other compilers.
Well, it's all C++ in the end, so you can include your C++Builder files into a VS2005 solution and link the libraries in. VS2005 would much rather see MFC or .NET than all of the Turbo classes from C++Builder, no doubt. Importing resources may be an issue too.
I'd be interested in other answers here as well. We may need to travel down this same path on our project.
Is it possible to switch off managed code (and switch on unmanaged code) for c++ coding, so that programs (exes) made are run direct to native machine code in Visual Studio 2008?
Also, is it true that after the first time a .net (managed) exe runs (say written in C#) the exe gets converted to a native code one (like the old c++ ones pre .net)? Or is there a way to make it compile direct to native code if it was written in C#?
The answer to both of these questions is yes.
You can create unmanaged c++ code projects in VS which do not need .Net. You can also link unmanaged C++ code to managed C++ code and (sort of) get the best of both worlds - although the matching of calling parameters between the to systems is interesting.
You can also use the ngen .Net utility to pre-compile .Net projects to pure code. However in doing so you loose some flexibility. The JIT compiler will take account of local capabilities when compiling a .Net project. So if you distribute a .Net project as generated by VS then ngen on the local machine that runs the program will do the compiliing. However if you use ngen on your machine the precompiled code will be tied to the processsor capabilities of your system.
As per Joel's comment. regardless of using ngen or not, you still need .Net framework on the target machine.
In thinking about it, the use of ngen to pre-compile a .Net project probably is no worse than compiling an unmanaged c++ project to native code.
To do what you want for C#, you would use ngen.exe, which comes with the C# compiler. You run that command on the image, and it gets added to the GAC as native code.
As far as i know, you can switch temporarily to unmanaged code, i.e. using unmanaged variables etc. by marshaling. Take a look here: http://msdn.microsoft.com/de-de/library/bb384865.aspx