Dcu in Delphi XE2

1
votes

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.

2
delphidelphi-xe2firemonkeycross-compiling
That link does not suggest that the dcu file compiled on a Mac is platform independent. I believe that a separate Mac compilation is required, and the dcu produced will not be compatible with a dcu produced by compiling under Windows (nor would I expect the 32 bit and 64 bit compilations under Windows to be compatible with each other. – Larry Lustig
@Larry Lustig, it supposed to be otherwise, object files are CPU specific, but not OS specific. However, no one will tell for sure, dcu file format is internal and private. AFAIK, nobody does research on this subject currently. – Premature Optimization
@Downvoter It's not that simple. Object files are specific to the CPU and also the platform ABI. Mac and Windows have very different ABIs. – David Heffernan
@David Heffernan, in general case ABI is not an issue. However, granted, any attempt to interoperate with OS will break such "portability". – Premature Optimization
@Downvoter ABI most definitely is an issue. Think about the stack alignment requirements on Mac. And there are plenty more reasons why ABI matters. – David Heffernan

2 Answers

9
votes

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.

3
votes

To make it somewhat more insightful, some background info:

DCU's are more or less a combination of the following parts

  1. The object code, which is normal statically compiled relocatable object code, just like what C or C++ would generate.
  2. debug code inclusive (a Topview variant if I'm not mistaken)
  3. A precompiled header(interface) in some form.
  4. unspecialized generics in some representation (*)
  5. 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:

  1. not yet finally linked (object) code is slightly easier decompilable
  2. code with attached debug code is slightly easier decompilable.
  3. however the DCU format is version dependent and proprietary.
  4. 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.