Hello,

I generates some PPUs in a version of FPC. I try to use it in other version of FPC, but it not compiles.

So, can I disable the PPU version checking to I use my PPUs in any versions of FPC?

Thank you!

No you can't. The PPU version is there for a purpose. We increase it if we did incompatible changes in the PPU file format and thus older compiler versions would error out with cryptical errors. That's one of the reasons why it might be more reasonable to use releases, because there the PPU version is fixed.

Regards,
Sven

It won't help, we don't change the ppu version for fun but when the format changes.

2013/2/21 Sven Barth

Hum... I imagined that. Delphi also works in this way.

Thanks.

2013/2/21 Florian Klämpfl

So the only way that I see for using protected code and keep compatibility with any version of FPC, is implementing it in libraries.

Thanks Florian and guys! :)

compatibility with any version of FPC, is implementing it in libraries.

Thanks Florian and guys! :)

Or you provide units only for released versions (e.g. 2.6.0, 2.6.2, etc).

Regards,
Sven

2013/2/25 Sven Barth

Yes. Very nice. Thank you very much! :)

This is a major pain to quite a few users - I have some units for which source is lost from v2.4. Surely some of the reasons for the changes in ppu version would _not_ cause a problem with later versions if one isn't using this particular feature?

Maybe someone could generate a (binary?) patch to disable the check (at user's risk)?

John

John Lee wrote

This is a major pain to quite a few users - I have some units for which source is lost from v2.4. Surely some of the reasons for the changes in ppu version would _not_ cause a problem with later versions if one isn't using this particular feature?

This is the same problem one has with Delphi.

Maybe someone could generate a (binary?) patch to disable the check (at user's risk)?

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.

Regards,
Sven

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.

Tomas

Is the project one that can use shared libraries? Or does the code require inheritance from the code you want to hide the implementation of?

Jeff.

2013/2/25 DaWorm

Is the code for a component that will be commercial. It will use classes and inheritance.

Just state that your binary packages will only support selected releases. Most developers who buy components (and thus likely work for some company) are more likely to use stable versions anyway. E.g. altough I know about the many nice improvements in 2.7.1 I only use 2.6.0 (and in the future 2.6.2) for development of the Free Pascal based programs in our company.

Regards,
Sven

I'm guessing that you'd need to be pretty au fait with fpc internals & the code to do this eg because there's no spec, and no tools to help? J

2013/2/25 Sven Barth

Now, with the arrival of FPC 2.6.2 I believe that I'll use PPUs. Is very annoying maintain DLLs/SOs. :S

Thank very much friend! :)

John Lee wrote

I'm guessing that you'd need to be pretty au fait with fpc internals & the code to do this eg because there's no spec, and no tools to help? J

One would need to combine the original version of the PPU loader (as included within the compiler source of the respective FPC version) with the PPU writer of the latest version. I don't say that it would be easy though (that's why I talked about sufficient motivation - it is probably easier to rewrite certain stuff to which you lost your sources unless it is a fairly big project).

Tomas

John Lee wrote

I'm guessing that you'd need to be pretty au fait with fpc internals & the code to do this eg because there's no spec, and no tools to help? J

ppudump.

If I'd lost the source of a unit I need (if the unit isn't too big), I'd just ppudump the .ppu and write a new wrapper unit linked via externals with the original .o.

what are you calling a library? you could also use OBJ files which get linked in... i used to do this with TP5 (at least that far back)... i suppose an OBJ file can be called a "library" in the general sense of the word ;)

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.

DoDi

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

this

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

This sounds like the best plan if one has several .ppus - as some ppl seem to have & no source code, that should - but not sure what's involved with writing the wrapper. Could the whole thing be written in fpc pascal?

Would it be easy to reuse the wrapper for different .ppus? If so this'd be useful fpc tool.

What do others with this problem think?

J

In our previous episode, John Lee said:

I would not bother recovering the ppu's.

Since RTL and codegeration changes might cause other trouble for non trivial cases (specially between major versions), I would say it is not very practical.

IOW the possibilities are mostly theoretical, and if you are really in a hurry, stop wasting time recovering and start rewriting the missing source.

... and make sure you back up source next time.

+1

There are so many 'if's and "maybe"s that the end result is highly unlikely to produce a working binary. Even if you manage to get it working, there is no guarantee that the next FPC version will work.

The cartoon on http://developdaly.com/general/how-i-backup-everything/ says it all.

Michael.