As per my knowledge delphi files having same structure as win32 pe files. And the only difference in resource section i.e RCDATA resource section contains resource with name DVCLAL
My questions are:
Is there any difference in headers of win32 pe and delphi pe.
If there is no difference is no difference in structure then how to differentiate.
If there is difference then what it is?
What changes can be done by malware writers in delphi files.Any example.
What are the file formats of delphi file and win32 pe file.
There is no such thing as a Delphi PE file. Delphi compiled executables, on Windows, use the common platform format, which is PE.
Related
I use Delphi Seattle and my application has one 32Bit Exe and another 64Bit Exe.
For certain operations like MS Graph API I need these DLL's (libeay32.dll and ssleay32.dll).
Both Dll's have the same names, how can I ensure my Exes use the matching Bit's DLL.
All my work is in a single folder
I was hoping the 64 bit dll's would not have the name as ...32.dll
You can't have the 32bit and 64bit DLLs in the same folder, since their filenames will clash, as you noted. So, put them in different folders instead, and then at runtime you can have each EXE call Indy's IdOpenSSLSetLibPath() function in the IdSSLOpenSSLHeaders unit to tell Indy which folder to load the DLLs from.
I used Glut headers in visual studio but now I want to use it in delphi.
I can not find headers for delphi !
Glut folder contains:
glut.h
glut.def
glut32.dll
glut32.lib
How can I use them in delphi?
Is there any different header for delphi?
In order to link to the DLL from C++ you need the header file (.h) for the compiler and the import library (.lib) for the linker.
For Delphi you cannot use either of these files. You need to translate the header file to Pascal. An example of such a translation is the Windows unit in the RTL, Windows.pas. This is a translation of various Windows header files, windows.h and more.
You need to search for a Delphi translation of the glut header file. If you cannot find one, you need to write your own translation.
Start here: http://www.google.com/search?q=glut%20delphi
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.
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.
Up until Delphi 2007 I was using DelphiZlib 0.2.99 for decompressing gzipped files. In Delphi 2009 the library does not compile anymore. Besides the conflict with Delphi's own zlib.pas unit, the code generates a number of string-related compiler errors and warnings which I don't think I can fix without a close understanding of the library code. DelphiZlib code was last modified in the year 2000, and it does not seem to have been updated since.
What can I replace it with for Delphi 2009? All I need is to decompress *.gz files. This is for a freeware project, so I strongly prefer free-with-source solutions, but I'll consider commercial libraries too.
Have a look at Abbrevia