[fpc-devel] PPU version checking

Sven Barth pascaldragon at googlemail.com
Tue Feb 26 09:00:32 CET 2013


Am 26.02.2013 07:33 schrieb "Hans-Peter Diettrich" <DrDiettrich1 at aol.com>:
>
> Tomas Hajny schrieb:
>
>>> If you'd disable the check you would not be able to use e.g. a 2.4 unit
>>> with 2.6, because the PPU format is different and thus you'd definitely
>>> (not just perhaps!) get errors when the compiler reads the PPU file.
>>
>>
>> In other words: _If_ someone is motivated enough for such a task, it
would
>> be possible to create a convertor from one PPU version to another (and I
>> don't mean a "convertor" only changing the version number but something
>> that really loads the original format of the particular original version
>> and stores the data in the new format with new version). I don't think
any
>> of the core developers would be interested in such a task (at least not
>> just for fun because it would not be much fun most likely), but I don't
>> want to talk for others.
>>
>> Moreover, note that in addition to PPU version number you also have
>> dependencies related changes in RTL and packages. In other words, you
>> would need to convert the originally used compiled RTL+packages units
this
>> way together with your own (compiled) units in order to be able to use
>> those units with the new compiler.
>
>
> This is where a decompiler could help. It reconstructs the source code
from the old PPU, which then can be adoptede and compiled with a newer
version.
>
> A PPU decompiler is somewhat easy to create, as is for object files of
other OO languages, in contrast to an decompiler for executables of an
unknown (or multiple) compilers. I wrote decompilers for many compilers,
but never for Pascal because I wanted to protect the work of the users of
this language.

You need to differentiate here. The compiled code is located in the .o
files while the .ppu files contain the information for the compiler to use
a compiled unit again (symbol information, definitions, generic token
stream, inline node information).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130226/ce62c94e/attachment.html>


More information about the fpc-devel mailing list