I asked this question yesterday about using the Cygwin compiler to produce a C++ DLL that can be used by .NET: Using C++ app in .NET
The solution was to compile the C++ application using Visual C++ rather than Cygwin i.e. I was able to call a C++ function from .NET.
Why am I able to do this in Visual C++ and not Cygwin? The code can be found in my linked question. Here is a screen shot of Dependancy Walker for the Visual C++ DLL in case it helps answer my question:
Name mangling schemes are different in gcc/mingw/cygwin and msvs. You'll have to use the pure-C interface if you want to share DLLs between compilers.
Alternatively, you could use .def files as is described in the bottom answer to this question: How to use libraries compiled with MingW in MSVC?
Related
I am trying to compile a C++ library for use with C# on Windows (the library is Vanetza).
The library uses CMake, I am building from Microsoft Visual Studio Community 2022 (64-bit). I can build the library as shared DLL no problem. For use with C#, I thought of compiling the library as C++/CLI (common language runtime support enabled). At first, I could not compile it because the project uses Boost, but some compilation issues were solved by surrounding every Boost include with #pragma managed(push, off) and #pragma managed(pop).
Issue which blocks me now is that <future> header cannot be used with C++/CLI - I am getting this compilation error from lot of different places:
Severity Code Description Project File Line Suppression State
Error C1189 #error: <future> is not supported when compiling with /clr or /clr:pure. geonet C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\future 13
and I cannot solve this. I think that some Boost module that is used needs this header.
Is there any solution to this or is there another approach that could be used?
I need not only to get to some C++ functions of the library, but also to use some of its classes and to see some of its structures.
I tried compiling the library as normal C++ and then make an interfacing C++/CLI library which would be called from C#, but the header is again used somewhere.
I think that using P/Invoke (DLLImport) is impractical for me as it is only making possible to use C/C++ functions, but for classes and structures it cannot be used (as I understand it).
Is only possible solution to rewrite the parts that need <future> myself using C# constructs as mentioned in this question?
As per other similar questions, it seems that sometimes the project can be built such that Boost works without any problems and sometimes major code rewrite is needed. Could someone recommend me what would a usable approach would be in my case? I could use older Boost version (namely 1.58.0), but I do not know if it would help.
Write a class in c++/cli that connects to your C++ code. The code will call the router which I presume will return a future. Then in manged/cli you create a task that hooks up to that future. So you have the original code compile to a static C++ lib and link that into your managed C++/cli dll
I have to decompile obfuscated dll which was written in Microsoft Visual C++ 6.0 DLL?
How can I do that? I have tried so many software .Net Reflector,JetBrains dotPeeks but they all seems useless :(
If you just need to use the functionality of the DLL, use LoadLibrary and GetProcAddress instead to dynamically load the library and obtain function pointers.
You can use Dependency Walker if you need to see what functions the DLL exports (but it would be easier if you just had a header file for it on hand).
Microsoft Visual C++ compile code into native x86 code (not CLR).
For decompiling native code into c/assembler you should use IDA Pro with the "hexrays" plug-in.
http://www.hex-rays.com/products/ida/index.shtml
I work on the optimization algorithm so the performance really matters. The algorithm is about 8 times faster when compiled in VS 2010 compared to VS 2008. Googling shows that it is not my fault (see e.g. https://stackoverflow.com/a/5560184/890355). The problem is that the final project must be built under VS 2008.
The solution I tend to is to built my algorithm as DLL in VS 2010 and then link it to the main project. Is it possible to use VC++ 2010 run-time libraries with my DLL under VS 2008? If so, what is the least painful way to do it?
Any other ideas?
Thanks.
The runtimes are not an issue. Nothing stops you from linking your DLL against the VC2010 runtime and then using that DLL in other projects. It doesn't matter if those projects are built using Visual C++ 2008 or any other language.
The tricky part is designing the DLL interface. Simply exporting some C++ classes is risky since it exposes you to incompatibilities between the different compilers. I think your best bet would be to either expose a C-style interface or use COM. I think COM is the best approach, but if you're unfamiliar with the technology, then a C-style interface will work fine. (COM could also be over-kill if the interface is simple.)
If you ask for any other way to combine 2008 and 2010 libraries in one executable other than moving 2010 part outside into a DLL, than the answer is probably "there is no other easy way to achieve this".
But if you don't want to "VC++ 2010 run-time libraries ... under VS 2008" (that is building against 2010 libraries in old 2008 IDE), but "use a 2010-compiled DLL in your 2008-compiled program", it is perfectly possible.
The easiest way, as we do it in our projects, is to build (both .exe and DLL) against statically linked standard libraries (MFC, if you use it) and then use LoadLibrary in your .exe to load the DLL. In the DLL you can export (_declspec (dllexport)) a function (preferably inside extern "C" {} guards) and use it in the .exe through GetProcAddress.
Static linkage and explicit loading save you from a lot of inconsistency bugs caused by different runtimes.
If you are worried about DLL loading and function calling costs, you can try to make these calls as rare as possible (maybe by moving not only the algorithm, but also some more high-level logics into the DLL). See this issie too.
And you can build all your code in one IDE (2010) using native multitargeting (however you will still need to build you main app and DLL separately against v9 and v10 libraries respectively).
You can if you're careful, and the MS documentation provides some hints. I have answered this question before here:
Wondering if the lower version of visual studio can use the dll built using higher version of visual studio?
Thinking of using MinGW as an alternative to VC++ on Windows, but am worried about compatibility issues. I am thinking in terms of behaviour, performance on Windows (any chance a MinGW compiled EXE might act up). Also, in terms of calling the Windows API, third-party DLLs, generatic and using compatible static libraries, and other issues encountered with mixing parts of the same application with the two compilers.
First, MinGW is not a compiler, but an environment, it is bundled with gcc.
If you think of using gcc to compile code and have it call the Windows API, it's okay as it's C; but for C++ DLLs generated by MSVC, you might have a harsh wake-up call.
The main issue is that in C++, each compiler has its own name mangling (or more generally ABI) and its own Standard library. You cannot mix two different ABI or two different Standard Libraries. End of the story.
Clang has a specific MSVC compatibility mode, allowing it to accept code that MSVC accepts and to emit code that is binary compatible with code compiled with MSVC. Indeed, it is even officially supported in Visual Studio.
Obviously, you could also simply do the cross-DLL communication in C to circumvent most issues.
EDIT: Kerrek's clarification.
It is possible to compile a large amount of C++ code developed for VC++ with the MinGW toolchain; however, the ease with which you complete this task depends significantly on how C++-standards-compliant the code is.
If the C++ code utilizes VC++ extensions, such as __uuidof, then you will need to rewrite these portions.
You won't be able to compile ATL & MFC code with MinGW because the ATL & MFC headers utilize a number of VC++ extensions and depend on VC++-specific behaviors:
try-except Statements
__uuidof
throw(...)
Calling a function without forward-declaring it.
__declspec(nothrow)
...
You won't be able to use VC++-generated LIB files, so you can't use MinGW's linker, ld, to link static libraries without recompiling the library code as a MinGW A archive.
You can link with closed-source DLLs; however, you will need to export the symbols of the DLL as a DEF file and use dlltool to make the corresponding A archive (similar to the VC++ LIB file for each DLL).
MinGW's inclusion of the w32api project basically means that code using the Windows C API will compile just fine, although some of the newer functions may not be immediately available. For example, a few months ago I was having trouble compiling code that used some of the "secure" functions (the ones with the _s suffix), but I got around this problem by exporting the symbols of the DLL as a DEF, preparing an up-to-date A archive, and writing forward declarations.
In some cases, you will need to adjust the arguments to the MinGW preprocessor, cpp, to make sure that all header files are properly included and that certain macros are predefined correctly.
What I recommend is just trying it. You will definitely encounter problems, but you can usually find a solution to each by searching on the Internet or asking someone. If for no other reason, you should try it to learn more about C++, differences between compilers, and what standards-compliant code is.
I'm looking to compile some old source code in Visual C++. However, the first of many errors I am receiving is:
vcl.h: No such file or directory
This appears to be in reference to the Visual Component Library, native to Borland compilers it seems. I downloaded the free Borland C++ 5.5 command line compiler, but it doesn't seem to contain a vlc.h in its include directory.
How can I resolve my issue? Many thanks.
This old code must have come from C++Builder. If it actually uses the VCL, you won't be able to build it with any other compiler. If there are other VCL includes like classes.hpp, system.hpp, controls.hpp, etc. it is using the VCL.
If it is a console application and doesn't actually use any VCL classes, then you can probably just remove the include, but the chances are slim.
Borland C++ 5.5 and C++ Builder are two different products.
The VCL components are in the C++ Builder product and can't be compiled with Borland C++ 5.5 which is a pure C/C++ compiler (I think OWL is included there).
So you have to get your hands on C++ Builder to be able to compile it.