I need to use a 3rd party code/dll in my .Net service. I did some research. But I can't find any direct answer for this. Mostly are recommending to port the code into VS C++ .net using a wrapper class. At the same time since there are VCL-headers used which has no replacements in VS C++. Can someone guide me on this please?
The VCL files in use are : Classes.hpp, Sockets.hpp and, ExtCtrls.hpp
Thanks in advance.
A DLL written in C++Builder works just fine in C# provided that the DLL exports flat C-style functions that use basic interop-safe data types and calling conventions that are portable across multiple compilers. Or the DLL implements a COM object (since COM has a standardized ABI). This is no different than writing any DLL that can be used in multiple languages including Delphi, VB, Java, Perl, PHP, etc.
You can't use VCL headers directly in the DLL's public interface, since VCL is not portable to non-Delphi/C++Builder compilers. But you can hide the VCL code behind an abstraction layer that is portable.
Related
I have a C/C++ .dll containing core functionality of my program, and a Delphi project for the graphical user interface.
Is there any way I can export something like a std::vector or std::map to Delphi and use it in C++?
Thanks in advance
C++ classes can only be directly consumed by C++ code. Similarly, Delphi classes can only be directly consumed by Delphi code.
An exception to these rules is that Embarcadero's compilers have interop support and it is possible to consume some Delphi classes from C++ code, so long as the C++ code is compiled using an Embarcadero compiler.
Assuming that you are not using an Embarcadero C++ compiler you will need to wrap any classes that you wish to export in an interop friendly manner. The obvious choice for this is COM which was designed to solve this very problem.
I have a C++ *.h file with three classes in it. The header file is for accessing a DLL. I have almost no C++ knowledge. However, I seem to recall from somewhere that you can't convert a *.h file to a Delphi unit that has classes in it. Is this true?
If it isn't true, and classes in header files aren't a problem, what is the general approach to converting the classes to Delphi?
C++ classes, just like Delphi classes, are not designed for binary interop.
A Delphi class can only be exported for consumption by other Delphi code, and then only in a package, and only when runtime packages are in use, and only when all modules use the same version of Delphi. In a similar vein, C++ classes can only be imported from a DLL by code compiled with the same tool chain that compiled the DLL.
So, it is not possible for your Delphi code to consume this DLL. As I see it you have the following options:
Persuade the supplier of the DLL to provide an interop friendly interface to the library. For instance, a plain functional C style interface, or a COM interface.
Write an adapter in C++, using the same compiler that was used to build the DLL. That would involve you importing the classes into your wrapper and exposing them to your Delphi code in an interop friendly manner. Again, plain C style interface or COM are the obvious choices.
In the sense of allowing you to use the DLL from Delphi code? Yeah, good luck with that. You know how you can't use Delphi classes in a DLL unless the client code is written in the same version of Delphi and even then it's usually a bad idea due to shared memory management gotchas? C++ poses exactly the same problem, only exponentially worse because there's no standardized ABI and there's all sorts of C++-language screwed-uppedness making problems for you.
The only real way to make it work reliably is with an interface that uses a standard ABI. If you have the source, try making a C interface that wraps the C++ interface. If not, ask the person who wrote the DLL to provide a C interface, and ask whoever made the decision to use this DLL why you're using a 3rd party library with no source available. :P
As commented in a previous answer the solution is using SWIG in order to generate the pascal binding. I started the development of the SWIG's pascal module but I had not time to complete it. Basically it works but it lacks all the test cases to be integrated into SWIG.
I used it in my personal projects and I was able to import complex library as GDAL.
I have a need to create a C++ non-dotnet DLL that will be called and used by a VB.net application. I am trying to determine the type of DLL to create. The DLL will contain some classes, variables, and functions that I will be writing. I understand that there are three types of a DLL that can be created: 1) Regular DLL - Statically Linked to MFC, 2) Regular DLL - Dynamically Linked to MFC, and 3) DLL that uses the Standard Windows Libraries, non-MFC.
My question is, which would be the best to use, one that is linked to the MFC, or one that uses the standard windows libraries? Can someone make a suggestion and explain the differences between MFC and the standard libraries?
Thanks!
Gary
Microsoft Foundation Classes (MFC) are a relatively thin C++ wrapper around the Win32 API, with an emphasis on UI coding. You won't need to statically or dynamically link MFC to your DLL unless you are making use of MFC facilities such as its container classes or trying to display UI written with MFC in your C++ DLL. These are unlikely scenarios.
People have been calling unmanaged code from VB.NET since .NET began. There's a whole wiki available on the subject here at http://www.pinvoke.net/ and there's a useful walkthrough on CodeProject, http://www.codeproject.com/Articles/6243/Step-by-Step-Calling-C-DLLs-from-VC-and-VB-Part-2 as well. I recommend starting there.
It's a little more complex, but you can also write managed code in C++ by using C++/CLI that can be referenced just like any other managed code assembly instead of using platform invoke. You can use it to create VB-callable managed interfaces that call unmanaged, plain old C++ code. There's an introduction to C++/CLI on MSDN at http://msdn.microsoft.com/en-us/library/ms379617(v=vs.80).aspx and a quick example of using it as a shim for unmanaged C++ in this MSDN Blog entry: http://blogs.msdn.com/b/junfeng/archive/2006/05/20/599434.aspx
With native c++, I mean, not managed c++, not cli, not any special things from microsoft, I can:
1) get high performance
2) use existing c++ code library and engine
3) write cross platform code (for example, for ios and android)
it needn't be fully native c++, I can use managed code to do the ui things, like object-c in ios and java in android, but beside interface, can I use native c++ code?
I suggest you have a look at the presentation here: Using the Windows Runtime from C++ and especially at the comments from Herb Sutter. I quote:
Please answer this question: If I decide to write C++ GUI application
in Metro style am I forced to use all these proprietary ref, sealed,
^, Platform::String^ extensions for GUI components or not?
#Tomas: No, you are not forced to use them. We are providing two
supported ways:
1) These language extensions (C++/CX).
2) A C++ template library (WRL), see
Windows Kits\8.0\Include\winrt\wrl as Yannick mentioned. WRL is a C++
library-based solution sort of along the lines of ATL, which offers
what I think you're looking for -- template wrapper/convenience
classes and explicit smart pointers and such.
Yes you absolutely can, real native C++ is fully supported.
You do however mostly have to use the new WinRT libraries to do an user interface or system calls and although they are native code and fully callable from C++ directly the interface to them makes it very painful indeed to do so, as everything is a reference counted COM object and in addition it's not so easy to create instances of them as just calling "new" so you have to write a lot of ugly code to do so.
As the earlier answer said, microsoft provide two ways to help with this. One is via language extensions to c++ and the other is a c++ template library. Personally I consider both to be rather ugly for doing something as simple as calling an API but that's just me :)
But to answer your question, it's completely possible to write your application in real native c++. You won't need to use managed code at all for anything. But you'll probably want to use either the language extensions or the template library to make calling the API more easy.
Personally I'm hoping someone writes a wrapper for WinRT that exposes the most necessary functionality as a more usable c++ native library and then everyone can just use that from c++ instead...
Considering Simon Mourier's answer to this question:
Processing Microsoft Office Outlook 2003/2007 email messages…
I plan to use the PST File Format SDK which is written in C++.
I would take this opportunity to learn more about C++ and to renew with it, since it's been quite 15 years since the last time I used it. I have already downloaded and configured Boost 1.45 which is required to work with pstsdk.
Now, I'm currently writing a Windows Forms application using CLR C++ and plan to use the pstsdk to read from PST files.
Does it matter in any way that I'm using both CLR C++ and pure C++ altogether?
Shall I consider using it a different way, or is this okay?
If you want to use a .NET (Windows Forms, or maybe even the newer WPF) user interface, the simplest approach is to build an object model in C++/CLI, implemented in terms of the native code but having a .NET interface.
Then write the UI in C# and call the C++/CLI object model (which differs from using the .NET base class library in only one way -- you have to add a reference to the C++/CLI assembly... but the C++/CLI compiler will create all the metadata that C# uses).
You can mix managed and unmanaged code, but it will be a pain to marshal everything except the built-in types across the boundaries. It's much easier to stay with more powerful unmanaged C++. You could use CodeGear C++ Builder for example (or QT). The problem with CodeGear is compiler isn't that great, so you won't be able to compile everything from Boost, but you might not need that.
C++/CLI is intended to interop with unmanaged C++- that's pretty much it's entire purpose. However, I feel that it's probably easier to write in C# if you need .NET for, say, WPF, which is an excellent technology, and just use C++/CLI for interop.