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.
Related
Is the *.dcu files in delphi xe2 for firemonkey application are independent from platforms.
here. for both 32bit and 64 bit and other operating systems.
If so how is the dcu files are designed. is it something similar to the previous(delphi 1-delphi xe) or something like an intermediate language(like java or .net)
is this new dcu going to make the decompilation of dcu files easier.
The main intention of this question is to know some details about the pros and cons about the new dcu files for firemonkey.
Is the *.dcu files in delphi xe2 for firemonkey application are
independent from platforms. here. for both 32bit and 64 bit and other
operating systems.
No they are not; Delphi XE2 generates different .dcu files for different platforms, and .dcu files for each platform are created in separated folders.
To make it somewhat more insightful, some background info:
DCU's are more or less a combination of the following parts
The object code, which is normal statically compiled relocatable object code, just like what C or C++ would generate.
debug code inclusive (a Topview variant if I'm not mistaken)
A precompiled header(interface) in some form.
unspecialized generics in some representation (*)
cross-unit inlinable code (tree representation?)
I don't know if all these 4 are separate sections or that they are interleaved. My guess is that 1+2 are combined (since that allows more generic routines in the linker) and there is a "rest" with 3+4+5 and maybe some other metadata.
Since headers might depend on OS specific types and symbols in system unit and OS specific units, even in theory only the most self contained units could be crossplatform. Probably not worth the effort to bother.
As far as decompilation goes, it is pretty much the same as the general decompilation problem, with a few twists:
not yet finally linked (object) code is slightly easier decompilable
code with attached debug code is slightly easier decompilable.
however the DCU format is version dependent and proprietary.
the entire decompilation process is very compiler and -version dependent.
In short, it is probably not a bit easier than earlier Delphi compilers or even a static lib + header files of a random C++ compiler.
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/
My 32 bit Delphi 2010 application links to a number of C object files using the $LINK compiler directive. Can I do this in Delphi XE2 when targetting 64 bit?
I am currently compiling using bcc32 version 5.5, but I don't mind which compiler I use if it turns out that the Embarcadero C compiler does not yet output 64 bit objects.
Yes. You must compile the "C" objects files to COFF format. This usually means either the Intel and/or MSVC++ compilers. The same caveats apply to 64bit object file linking that apply to 32bit. You must ensure that all external references are properly resolved, either by providing another .obj which has that symbol, or from Delphi code. When building the "C" code, make sure you disable any stack checks or other run-time verification code generation. Many times such codegen relies on a specific version of the C/C++ RTL from the given tool.
Something else worth noting is that while Delphi 64bit can link to COFF object files (eventually it will also support ELF64), 32bit Delphi supports linking with C++Builder built OMF object files and, new to XE2, 32bit COFF object files which can be built with MSVC++. The same caveats apply.
Yes, you can link to OBJ files in 64-bit XE2 projects, but the OBJ files have to be 64-bit code.
Is there a way in Delphi 7 to generate a tlb from an idl? Or even from a class/ interface definition?
you can use the IDL2PAS.bat batch file (check in this location C:\Program Files\Borland\Delphi7\Bin) or the MIDL.exe application.
In Delphi 7 one of the easiest ways is to copy/paste the IDL into the Type Library editor source window. NOT the *_TLB.pas source unit 'behind' the type library, but the type library editor itself.
I don't have D7 to hand right now, but iirc you may have to set the "Type Library Language" option in the IDE settings to IDL rather than Pascal. And I also seem to recall that this technique could be sensitive to "exotic" IDL (i.e. didn't always work), but if the IDL in question is relatively straightforward, this may work for you.
in C# you can easily open an assembly (just another word from an EXE) and then get reflection information from that assembly. I've been looking for something similar for Delphi where I can write a Delphi program that can point to a Delphi EXE then get me reflection information. How can I archive this? Thanks
There are a handful of programs that can extract RTTI from Delphi programs and DLLs. It's not as rich as what's available for .NET, but it can be done to a limited degree. There's a lot more RTTI available in Delphi 2010 and later versions, but as far as I know there's no program out yet that can extract info from them.
I was at the conference where this system was formally announced, and a bunch of people asked how this would affect security. Barry Kelly, who created the new RTTI, said that there would not be enough metadata available to create a "Delphi Reflector".
Well, sad news is, you probably can't. You can easily view .NET assemblies because they a) are compiled to what is called intermediate language (thus you can even get the code back using the likes of Reflector etc.), and b) contain metadata. Delphi, on the other hand, compiles to native code that and produces regular PE files that do not include rich metadata like a .NET assembly.
Delphi just doesn't work that way.
There are tools that can assist in reversing (Delphi written) executables but it will never be easy and it requires good x86 assembly knowledge.
Some examples of such tools are:
IDA Pro and/or Hex Rays
DeDe
Interactive Delphi Reconstructor
PE Explorer
The resource sections of a Delphi Executable also reveals usefull info like the form and it's components.
See also Is there a program to decompile Delphi?
If you have Delphi2010+ you can load a bpl and then use the rich rtti over it lik. e you do with c# and a .net assembly. If you need to do this in a .exe AFAIK you can't.
TestComplete seems to identify most objects in a running Delphi executable. You can extract this information with a script. A demo can be downloaded from http://www.automatedqa.com/downloads/testcomplete
This is maybe not the type of application you want as it is big and made for GUI-testing, but yes it can identify the objects.
As mentioned Remko, IDR (Interactive Delphi Reconstructor) can extract all RTTI information (if program contains it!) for Delphi version from 2 to 2009. Version 2010 will be available later. Moreover IDR can use all information that it finds in program to create a lot of comments to disassemled program code (this is a first step of analyses). You can also look forms and easy go to event hadlers associated with controls.