[fpc-pascal] resourcestring and const arrays
Marco van de Voort
marcov at stack.nl
Sat Jun 25 14:55:01 CEST 2011
In our previous episode, Craig Peterson said:
> On 6/24/2011 4:14 PM, Marco van de Voort wrote:
> > No, this is a problem of gettext.
> It's a problem with FPC's resourcestring implementation, rather than
> something specific to gettext.
Well, then explain why Delphi + XE has exactly the same problem.
What you are trying to do is implementation defined.
> > For this to work you really need resource types that work based on
> > replacing memory areas, or use _()
> What do you mean by replacing memory areas? Runtime patching?
More or less. When localizing, the default windows resources model simply
loads a resource dll (containing the localized data including copies of all
forms, so an user can adjust e.g. the width of a text field) over the
addresses where in the main .exe the original resources are.
Gettext and other localization systems based are not based on this, but on a
system that intercepts a call to the resource handling system (loadresstring
iirc), and only work for resourcestrings (and not for the complete form
data). The _() is a shorthand for gettext
Hence their (gettext) behaviour in Delphi is exactly the same as in FPC.
> something exist that supports that? On Windows we're using resource
> DLLs directly, without going through gettext, so I really don't want to
> switch to _(). I don't mind low-level hacking though. ;)
> It looks like Delphi writes a table of these kinds of resource string
> uses and fixes them up during program initialization. If FreePascal had
> a similar table it could do the same thing as part of SetResourceStrings.
In 2.4.0+ resources should be mostly native. See the fpc-res package.
On Windows it might work, if it uses windows resources and its policy as
much as possible. But then you must also craft resourcedlls, and load them,
and not use something else like gettext.
More information about the fpc-pascal