On 15/08/2012 15:17, Rainer Stratmann wrote: > > Then the > mov pcharconst , EAX > command also had changed. > At every start of the program I see if it works here. > If it works here ist works outside also. > >> For example if you add/remove units and rebuild. > > All pchar adresses are searched at programstart. > >> For example if FPC internals decide to add or remove some padding in front >> of the constants. > > Very unlikely. > For which reason should there be padding in front?
For the reason that they always say not to rely on 'internal workings of the FPC' :) > I can not see any insolvable problem here. > Yeah. But it is labour intensive. >> Will all your translation work go to waste ? > > Then I would have a look at the opcodes directly and see what has been > changed > and likely find a solution. > See above. > If the maintainers decide to build in the suggested function above then > everthing is solved. By now no one of the maintainers wants this. > I can understand why, more or less - this could be a security flaw if you can find the final procedure call address like that [and then inject/patch it from outside, while the program is running - see what I mean?] Sort of the reason why Linux doesn't export System.map any more... And the sort of reason why (dx)gettext scans the _source_ not the binary. > I also can ask what happens if there are no more maintainers for fpc? Then you can fork it and maintain for you and for others for eternal glory :J Lukasz _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
