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.
Related
We are just starting on migrating some of our projects to 64-bit in Delphi, we also have a couple of 3rd party Delphi libraries that we are using.
Traditionally, when we use a 3rd party library we do so by using the design time package .bpl OR we just have the compiler compile the source code.
However, in 64-bit it seems we have to do it completely differently. If we are compiling a 64-bit library we need to use DCU.
For example, we have a library that we needed to use in 64-bit. The library supports 64-bit. To get it to work, I had to compile the runtime package as 64-bit then point the compiler to the outputted 64-bit DCU files. When I try to compile the library from source as 64-bit we get all kinds of errors.
So my question basically is: Why/How can we compile the source code through the runtime packages in 64-bit just fine, but when we try to compile as just source code in 64-bit we get errors?
To further illustrate just in case that wasn't clear:
A. Put all source files on search path. Compile program as 64-bit. ERRORS.
B. Open up supplied runtime .dproj from 3rd party library. Compile runtime library as 64-bit. Put outputted 64-bit DCU on search path. Compile program. Works fine.
Thanks
Edit: I'm going to be much more specific because it appears that i have failed in conveying what I'm trying to ask here.
We are using Clever Internet Suite 9.1 for Delphi.
We DO NOT use the design time package when compiling in 32-bit. We link directly to the source code through Delphi's search path. This works fine.
When I change my application to build as 64-bit We get this error:
[dcc64 Error] clSocket.pas(1971): E2089 Invalid typecast
A sample of the offending code (Slightly changed):
procedure cldostuff.WndProc(var Message: TMessage);
begin
if (Message.Msg = cl_const)
and (clSpecialType(Message).LookupHandle = FLookupHandle) then
begin
syncerror:= clSpecialType(Message).syncerror;
SetEvent(FCompleted);
end;
end;
The error is on the casting of the TMessage. I understand why TMessage would cause an error. I am not concerned about the error.
I am curious as to HOW compiling through a "package" works but not in DCU. Apparently I have misused the terminology of "Runtime package". I will post exactly what the clever developers told me on how to use in 64 bit.
The Clever Internet Suite fully supports 64-bit platform. The installer includes binaries for both 32-bit and 64-bit. Also, if you want to re-compile the library, you need to switch the platform option within the clinetsuite_x.dproj file, and recompile it (where _x depends on your Delphi version, e.g., in case of Delphi 10.3 Rio, the project file will be clinetsuite_103.dproj).
So I do Exactly that. I open up that .Dproj file and compile it. Once I do that it creates a Win64/Output folder that has ALL the dcus of the library. I can link to that and work in win64 bit just fine.
My questions is WHY does it work when I compile through the "Supplied .dproj file" but not when I compile through source code.
Hopefully I've done a better job of articulating what I am asking.
That compiler error is typically caused by a typecast between two value types of different size. If the code works in some compilation scenarios but not others then the obvious conclusion is that the record alignment options differ in those scenarios.
Most likely the package dproj file defines aligned records, i.e. {$ALIGN ON}. But your project does not. Perhaps it uses packed alignment, {$ALIGN 1}.
Make sure that all the units in the library are compiled with the same options as specified in the package dproj file. Typically that is done by the library providing an include file that specifies desired options and then the include file is included in all units. That insulates the code from compiler options specified in the host dproj file that are incompatible with those that the code requires.
You can add such a common include file since you have the source. In the longer term you should ask the developers of the library to make their code standalone and not require external specification of critical compiler options.
I am searching for a list of supported object file formats for each delphi version. Object files should be linked with something like: {$L lib/object.o}.
The Reason for this is a linker error in Delphi7 for a project i maintain. The error does not occur in compilers >XE3. I have only XE3 and above to test.
Has someone maintained a list or knows a reference to one where i can find informations about the supported format and/or changes with newer versions, maybe also problems with object files, etc?
I would like to help a user of the project with this problem (lz4-delphi issue).
The change came with XE2 which added support for the COFF object format. Prior versions only supported OMF objects.
The change to add support for COFF was driven by the new 64 bit compiler, introduced in XE2. Embarcadero did not have a 64 bit C++ compiler at that time and so needed to link objects produced by another compiler. They chose to use the MS compiler which emits COFF objects.
Allen Bauer's answer to a question that I asked contains more detail.
In practical terms this means that for Delphi 7 you will need to compile the source code with bcc32. Or compile the C code with some other compiler but then link to a DLL.
For future reference, Delphi 10.1 Berlin and 10.2 Tokyo both support ELF64 format, and also COFF.
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.
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.
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W