Is there a real difference between C++ dlls and Delphi dlls?
A application loads only C++ dlls.
Changing calling convention to cdecl is of no use
Is there a way to find whether a dll is a C++ dll?
What is the advantage of that dll?
I mean a Delphi dll can have parameters and/or return type of Delphi.
Like that C++ dll may have some exclusive data type/
Thanks for any hint
C++ dlls can, of course, use or expose C++-specific items (C++ classes, template functions, etc.), and a Delphi DLL could expose Delphi-specific items (sets, strings, etc.). But if both are written properly, and only use things other languages can use too, there should be no difference.
Fact is that not all C++ or Delphi DLLs are written properly. Also the default calling convention in Delphi is register (__fastcall in C++Builder), while C and C++ by default use cdecl. But generally both languages should use stdcall.
The only way to use a DLL is to either get a header file (.h) for it, or a Delphi import unit. The .h file can be translated into an import unit. If you only have a DLL but none of these, it doesn't make much sense to try to guess the parameters of functions.
If you look at the DLL with TDUMP.exe or Dependency Walker, you might get a hint, as was said in another answer. Dependency on e.g. msvcrtXX.dll might be a good hint it is a C++ DLL.
You might also try to get a .tlb from the DLL. You can do this in the IDE (From memory: "Component menu" - "import component" or some such).
If you want to know the calling convention, read this, especially the part about finding out the calling convention.
Addition
Some C++ programmers forget to wrap their declarations in extern "C" blocks, so the exported functions are mangled. This could tell you which parameters are required, but you get ugly names. For this, Dependency Walker is a great help, as it can translate them (for VC++ generated or compatible DLLs at least). It makes using those functions from a different C++ compiler or a C compiler pretty hard, though.
You can use Dependency Walker to examine the functions in DLLs:
http://dependencywalker.com/
Related
is there any tool like Borland "coff2omf.exe"for converting Borland OMF LIB format to
MS VC++ COFF LIB format ?
actually i want to create .obj file in delphi and use that in MSVC++ .
Yes, there is such a tool.
See this tool.
This utility can be used for converting object files between COFF/PE, OMF, ELF and Mach-O formats for all 32-bit and 64-bit x86 platforms. Can modify symbol names in object files. Can build, modify and convert function libraries across platforms. Can dump object files and executable files. Also includes a very good disassembler supporting the SSE4, AVX, AVX2, FMA and XOP instruction sets. Source code included (GPL). Manual.
Note that this http://www.agner.org web site is the best resource I know about low-level optimization. All the linked information is worth reading, if you want to deal with performance.
But for using the Delphi-generated .obj with VC++, it won't be easily feasible, but for very small part of code. You will need the Delphi RTL used in your code. An external .dll is much better. Note also that some types (like strings or dynamic arrays) won't be easily modifiable in VC++.
To the best of my knowledge there is no such tool. Using Agner Fog's object file converter, the tool that Arnaud refers to, I've never succeeded in converting a Delphi unit into a COFF .obj that can be linked to an MSVC program.
I do believe that it's not realistic to take Delphi source code, compile it, and then use the generated object in MSVC. The other direction is quite possible. You can compile C code to an object, and link that object to your Delphi executable. When you do this you need to resolve any dependencies that the compiled object has.
But to link a Delphi object into a C/C++ program is going to require whatever part of the Delphi RTL that you use. And that's going to be tricky unless you happen not to use any part of the Delphi RTL, which seems unlikely.
In your situation I think your options are:
Port the code to C or C++.
Compile the Delphi code into a dynamic library and link to that from your C++ program.
Can anyone recommend a FIX Engine (commercial or open source) for use with Delphi?
Is it possible to use QuickFIX with Delphi?
Take a look at B2BITS FIX Antenna. There are two possible options:
FIX Antenna C++ has ANSI C interface that can be used in Delphi (there is a sample in the package)
http://www.b2bits.com/trading_solutions/fix_engines/fix_engine_cpp.html
FIX Antenna .NET can be used in Delphi .NET (there is again a sample in the package; also programmer's guide contains Delphi.NET samples)
http://www.b2bits.com/trading_solutions/fix_engines/fix_enginenet.html
Feel free to contact me directly if you need more details.
QuickFix is a C++ project.
Both Python and Ruby use SWIG to expose the C++ classes as native Python and Ruby classes.
The .NET wrapper sounds like a mix of C++ and C# code.
It's not possible to import C++ classes within Delphi directly. You'll have to use a "flat API" conversion, exposing all C++ methods as plain C declarations, in order to import external structures and functions in a Delphi unit.
To my knowledge, there is no such "flat API" of QuickFIX available, and no SWIG version able to generate Delphi code. You'll have to write your own wrapper in C++, or perhaps write your own FIX implementation in Delphi.
The only FIX library I know for Delphi is the one from http://www.b2bits.com - it did exist some years ago, but I'm not sure it's still sold/maintained - they seems to maintain only a DotNet version. Worth asking them for pricing and availability, in all cases.
One way to integrate the protocol with Delphi would be building a .Net or Java bridge, for example:
use the .Net C# implementation to build a small application to communicate with the FIX side
then expose methods (and maybe even the objects) of this .Net app over SOAP web services
use Delphi's web service client code generator to import the SOAP WSDL
access the web service from the Delphi side
This is probably more of a hack than anything else, but you could use the Python QuickFIX bindings in Delphi, via python4delphi. That's a lot of layers though (Delphi to Python to C++).
Python is an easy language to use, and learn, and it's easy to invoke and create python objects (or native C wrappers that pretend to be python objects) and invoke them directly from the Python4Delphi API.
Barring that, it might be very little work for you to build a procedural (flat) API as ABouchez said. Instead of writing a million functions I would write only the ones I needed, and then implement these simple functions inside a VC++ DLL:
QuickFixInit;
QuickFixCleanup;
handle := QuickFixLoadFile(filename)
QuickFixSaveFile(handle)
handle2 := QuickFixGetObjectHandle(handle,index,...);
QuickFixModifyObjectProperty(handle2, propertyname, propertyvalue );
QuickFixExecuteSomeAction( handle2, actionname, param1,param2,param3 );
The above are just to give you the flavor. I know nothing about the internal API, but what I'm showing you above is that you don't need to conform 100% to the API to write a wrapper. You could probably (if you know C/C++) write a functional wrapper that does what you need, and export it, link it into a DLL, and then import QuickFix.dll into Python with very little (2-4 hours of an expert's time) work, if you know Visual C++ well enough to write a few simple C-style (non OOP) functions that instantiate C++ classes, and invoke C++ methods.
It might be possible to expose the C++ APIs to Delphi via a C++Builder package (BPL) containing QuickFIx, but (a) some source modifications would be required, and (b) the C++ code in QuickFix, or its dependencies, might not build in C++Builder without significant modifications.
I'd like to use a .dll with a delphi application, but I'm curious if a delphi package is more flexible than dll?
You can read this article on my Blog: "DLL's, BPL's Static and dynamic loading, and Packages in Runtime"; Is 's writed in Spanish but you can try the Automatic translation (on right part of the page).
Basically BPL is an extension of a DLL. It's a DLL with some things added.
(POSITIVE) If you use BPL's you can do more things with the DLL. More power. You can use RTTI (you must build your applicaction with runtime package for accesss RTTI).
(NEGATIVE) If you use BPL's with more powerfull, you can only use it with Delphi, no with other languages.
If you're sure that you only use it with Deplhi, I think that you must use BPL. Search samples about RTTI, RegisterClasses, GetClass method, LoadPackage (for dynamic load),...
Regards.
Escuse-me for my poor english. It's not my natural language.
Not knowing excactly what you mean, and believing you are a newbie (so I may omit some specialized aspects), and implying you know what a DLL is:
The first and foremost reason to build a package is authoring a design-time component.
You can do quite everything (well..almost...) that a package does just as well with DLLs -- except for the design-time stuff.
Additionally, you can package multiple compiled packages into one Borland Package Library (BPL file) without having the design-time features in mind. If you think deploying and runtime-binding one BPL is better than various DLLs, go for it. The primary purpose is design-time support, though.
Packages are special DLLs that can export classes, while DLLs can only export functions. Yes, you can write a DLL function that creates and instance of a given class, but you can't use a class declared in a DLL (unless using some hacks maybe), while you can use a class declared in a package directly. Packages "know" about Delphi object architecture, while DLLs don't. On the other end, DLLs can be used from any language able to use them, while packages are Delphi-specific.
After this question, I need to know what principles should be followed in order to make an encapsulation of a class in a dll compatible to other version of Delphi.
I made a class using generics feature in RAD2010 and make a dll which has a function that return an instance of it. When I tried to use the dll using BDS2006 or Delphi 6, the DLL didn't work as expected. But if I use RAD2010 in other computer, there is no issue. Is it caused by using the feature that not available in previous Delphi version (the stack<> stuffs?)?
For string matters, I already follow the comment guidance in the library file, that I put ShareMem in both library first uses clause and my project. And I have copied borlndmm.dll from RAD2010 to the same folder where I tried the DLL using BDS2006. It didn't crash, but it didn't work es expected. A function return an empty string when in RAD2010 environment it worked very well.
Once again, I have a question : what principles should be followed in order to make an encapsulation of a class in a dll compatible to other version of Delphi? Thank you in advance. (For encapsulating functions in a dll when no OOP is used, I have no issued for other version of Delphi).
The definition of a string changed with D2009. If you want to make string communication safe, use a PAnsiChar or a WideString.
The basic rule of communication through DLLs is to not use anything specific to Delphi, so no Delphi strings and no TObject descendants. Interfaces, records and COM types work fine, though.
You ask:
Once again, I have a question : what principles should be followed in order to make an encapsulation of a class in a dll compatible to other version of Delphi?
and there is only one: Don't do it. You can't do it. Either you write a DLL, then use idioms and data types that can safely be used in DLLs, which precludes (among other things) classes.
Or you write a BPL, then you can safely export classes, use strings and such, but you are tied to the same Delphi version. This limitation is of technical nature, so writing a DLL will not work around it. There may be tricks to overcome this, and there may be different Delphi versions that use the same class layout so that it works, but you must not tie your public DLL interface to such implementation details.
Stick with only fundamental types. If you use interfaces, create them using the type library editor so your constrained by the compatible types by the start. A good rule of thumb is to look at the windows API and try to emulate its calling conventions.
You can use classes in your DLL, you just can't expose them as such. A good idiom that works well for DLL's is the handle concept. Your DLL creates an object and returns a handle to that object. When you need to work with that object again, you pass a function in the DLL a handle. Just remember that your DLL needs to be completely responsible for the memory and lifetime of the object. Its a trivial process to create DLL functions to expose the pieces of the class that you will need access too.
From the Delphi side, you can then write a proxy wrapper which hides the handle from the user. For events you can use a callback method. Basically you pass non object function pointers to the dll, which then invokes the function on the event. A quick overview of this process is available on Delphi 3000.
I read this article and find the concept of Virtual Library Interfaces nice for runtime loading of DLLs. However it seems that they aren't available for Win32. Is this true? And if so: Why? I don't see what would tie the idea to .NET.
EDIT: I'm mostly rephrasing here what Rob already wrote. :-)
I'm not after plugins or similar - it's about plain old Win32 DLLs. What appeals to me is the idea to let the compiler deal with all the details of loading a DLL at runtime - no need to call GetProcAddress for every function in the DLL etc.
It seems to me like the three answers so far have completely missed the point of your question. That, or I have. You're asking why Win32 Delphi doesn't have something like the magical Supports function that Hallvard's article talks about, aren't you? Namely, a function that, given the name of a DLL and the type information of an interface, returns an object that implements that interface using the standalone functions exported from the DLL.
Hydra seems to be all about calling .Net code from a Win32 program, not about importing functions from a DLL. TJvPluginManager requires that the plug-in DLLs export a special self-registration function that the manager will call when it loads the DLL, and the function must return an instance of the TJvPlugin class, so the plug-in DLL must be written in Delphi or C++ Builder. The Supports function, on the other hand, works with any DLL written in any language. You could use it on kernel32, if you wanted.
I don't know why Win32 Delphi doesn't have such a thing. Maybe CodeGear didn't see much demand for it since Delphi and Turbo Pascal had already gone for so long without it.
It's certainly possible to write a function that works like that, and I don't expect it would be any harder to write than the .Net version must have been, unless Microsoft's .Net libraries already provide most of the pieces and Delphi just wraps them up into a convenient-to-call function that looks like the several other overloaded versions of Supports that Delphi has had for years.
There would be a few steps to implementing that function in Win32. (I'm providing only a sketch of what's necessary because I don't have a running copy of Delphi handy right now. Ask nicely, and maybe I'll find more details.) First, you'd need to make sure that type information for an interface held, at a minimum, the undecorated names of its methods. Then, Supports would need to generate a function stub for each method in the interface (besides _AddRef, _Release, and QueryInterface). The stub would go something like this, assuming the calling convention is stdcall:
asm
// Pop the return address,
// discard the "this" pointer,
// and restore the return address
pop eax
pop ecx
push eax
jmp AddressOfFunction
end;
As Supports generated each stub, it would fill in the actual function address, gotten from calling GetProcAddress with the name of the corresponding interface method. The stdcall calling convention is easy to wrap like that; cdecl is a little cumbersome; register is a pain in the neck.
Once it has all the stubs generated, it would need to generate an "object" that looks like it implements the given interface. It doesn't have to be an actual class. At compile time, Supports doesn't know the layout of the interface it's going to be asked to implement, so having a class wouldn't accomplish much.
The final step is to provide implementations of the _AddRef, _Release, and QueryInterface. _AddRef would be unremarkable; _Release is where you'd call FreeLibrary when the reference count reached zero; QueryInterface wouldn't do much at all, except claim that it supports IUnknown and the interface given to Supports.
Delphi used to come with a sample program that demonstrated implementing an interface without any classes at all. It was all done with records and function pointers (which is all an interface ultimately is, after all). Delphi also came with the corresponding code to do it with classes, in part to show how much easier Delphi can make things. I can't find the name of the demo program now, but I'm sure it's still around somewhere.
There are a number of Win32 options for this type of functionality. Project JEDI has an open source plugin system as part of the JVCL that loads either DLLs or packages, and can include forms and whatnot as additional functionality.
There are also a number of commercial products available, including the TMS Plugin Framework and RemObjects Hydra.
This is nothing new or special. The article's just talking about plugins. Native code's been able to do plugins for years. The only special thing about P/Invoke is that it allows native code and .NET to talk to each other in a plugin system, and the little trick where "the DLL can be seen as a singleton object that implements the interface [so that] you can use the Supports function from the Borland.Delphi.Win32 unit to check if the DLL and all the methods are available."
If you want to do what the article's talking about in Delphi for Win32, look at the LoadLibrary, GetProcAddress and FreeLibrary Windows API functions. If you absolutely must have an interface like the article describes, you have to write it yourself, either in the DLL (if you wrote the DLL yourself) by writing an exported function that returns an interface, or in the calling app, by writing a function that uses GetProcAddress to create an interface dynamically. (Caution: this requires mucking around with pointers, and is usually more trouble than it's worth.)
Your best bet is probably just to do what Tim Sullivan mentioned: use TJvPluginManager from the JEDI VCL if you only need native code, or Hydra if you have to talk to .NET assemblies.
I've used Hydra myself for a Delphi only solution (i.e., didn't interface to .NET) and it works great for that too. It's easier to use and adds some niceties, but I think that it's basically implemented the same way as the "roll-your-own" plugin framework that is well-described in this article:
http://www.saxon.co.uk/SinglePkg/
I would look for a plugin framework that's interface-based (like Hydra and the "roll-your-own" system in above paragraph), rather than one that simply sends messages between apps.
There is a Delphi plugin framework on sourceforge, don't know whether it's the same one as in JEDI project or not: http://sourceforge.net/projects/rd-dpf
There are also a couple of other commercial solutions, one of which is Dragonsoft's:
http://www.dragonsoft.us/products_dsps.php
What is wrong with doing this with simple com objects? Declare a simple interface that all of your plugins implement, and require that each com object include an exported function that returns its class guid. Then using the "plugins" is as simple as walking thru the plugins directory looking for DLL's which expose the special registration function, invoking it and then using the class guid to then invoke the com object.
I used something like this in a WIN32 commercial application with great success. The advantage was I could switch plugins in and out at will (provided of course the application wasn't running to remove existing ones), the magic was all in the interface that each one implemented.