My question is like Delphi compiler generates and assign numerical Identifiers to all the ResourceStrings when application is compiled, There are few documents which says when ever application is recompiled the numerical Identifiers for Resourcestrings are regenerated, and they warn relying on it because it may change after regenerations. There ate so many third party localization tools that use and store this resourcestring numerical identifiers for internal reference and translation. Is there any way to stop compiler regenerating this resourcestring numerical identifiers or force it to use manually generated numerical identifiers?
You can get a resource-compiler, compilable file from the compiler by specifying the --drc or "Project|Options|Delphi Compiler|Linker|Output resource string .drc file" switch. This will instruct the compiler to generate a .drc file that will contain the resource string contents and the compiler-assigned values.
If you do this for each build, even if the compiler rearranges the assigned values, you will always know what they are. The compiler generates an identifier for each resource string based on the unit-name and the resource string identifier, so that is always stable even if the value changes.
This .drc file can then be translated or otherwise processed and then recompiled into a .res file. This .res file can then be linked into a a special "resource-only" dll with a specific extension other than ".dll" that indicates the language. When the system language is properly set, this dll will then be loaded and the strings will be used instead of the built-in resource.
You don't have any control over how the compiler generates the string table resource, and the numeric identifier.
If you wish to use external tools that rely on the numeric identifier then you should probably build the string table in the classic way. Define the string table in a text file. Compile to a resource and link into a language specific resource DLL. This will make the coding less convenient, and it's for you to decide whether or not that trade off is worth being able to use your external tools.
Related
I want to define a precompile string variable and use it in {$include} directive in delphi, for example:
{$define FILE_NAME "lockfile"}
{$include FILE_NAME'.txt.1'}
{$include FILE_NAME'.txt.2'}
...
For security reasons (this is part of our licensing system), we don't want to use normal strings and file reading functions. Is there any capability for this purpose in Delphi?
The $INCLUDE directive does not support indirection on the file name. So, the following code:
const
someconst = 'foo';
{$INCLUDE someconst}
leads to the following error:
F1026 File not found: 'someconst.pas'
If you must use an include file, you must apply the indirection by some other means. One way could be to use the fact that the compiler will search for the included file by looking on the search path. So, if you place each client specific include file in a different directory, then you can add the client specific directory to the search path as part of your build process.
FWIW, I find it hard to believe that this will make your program more immune to hacking. I think that a more likely outcome is that your program will be just as susceptible to hacking, but that it will become much more difficult and error prone for you to build and distribute the program.
You requirement may be better satisfied by the proper use of a VCS system. You need "branches" for every customer where customer-specific files contains customer-specific data. This will avoid to litter your code with complex directive to manage each customer - file names stays the same, just their content is different in each branch. Adding a new customer just requires to create a new branch and update files there.
Then you just need get each branch and compile it for each customer to get the final executable(s) with customer specific data built in.
I have a Delphi app with localized resource DLLs.
I would like to do a search and replace on a resource string once it is loaded from the DLL.
Is there any internal procedure to hook into to do this?
I need a way to just do search and replace for any resource string loaded, and not just change a specific resource string.
Raoul.
Yes you have to hook the LoadResString() procedure defined in System.pas.
See for instance how we do in http://synopse.info/fossil/finfo?name=SQLite3/SQLite3i18n.pas
There is everything in this unit code:
For extracting all resource strings (but you may also compile the executable with the "detailed map" option to get the same list);
For replacing all resource strings on the fly, to your expected language;
For caching all resource string, since default LoadResString API can be slow.
You have also similar code around, but this is one included in our Open Source mORMot framework, working from Delphi 6 up to XE2. There is also code to change on the fly all .dfm content (i.e. your forms), from the same translated text file. There is a chapter about that in the framework documentation at http://mormot.net
I think you will get here every code pattern needed for your task.
The example I am looking at is in the TurboPower FlashFiler database.
It has, for example, a file ffclcnst.rc which contains
FF_CLIENT_STRINGS RCDATA FFCLCNST.SRM
and I can run
BRCC32 ffclcnst.rc
at the command prompt which seems to compile the .SRM file into a .RES file, but I cannot see how to change the information in the .SRM file. It appears to come from the ffclcnst.str file so I assume there is some way to convert the .STR file into the .SRM file.
The readme tells you:
Most of FlashFiler's error messages are stored in string resource
files having the extension STR. If you change these files, you must
recompile them using the TurboPower String Resource Manager located at
http://sourceforge.net/projects/tpsrmgr
Please note that these are not standard Windows string resources. They're something TurboPower made up. For a full explanation, be sure to read the String Resource Manager's documentation. You can make an ordinary string-table resource in your .rc file, or you can skip the .rc file altogether and declare resourcestring constants directly in your Delphi code. Unless you're editing TurboPower code, or you need to support ancient Delphi versions, I recommend you just use normal string tables.
I need to patch a method in Classes.pas
(TReader.ReadString - I want to force it to use a specified codepage, not the system default).
If I copy Classes.pas into my project,I will end up having to rebuild the entire VCL. Is there any (easy) way to patch a method at runtime?
Modifying the implementation side of Classes.pas will not require recompiling everything. Delphi figures out if a unit needs to be recompiled by an algorithm that looks roughly like this:
If DCU found:
Is DCU format out of date (old version of compiler)? If so, need source to recompile or compile-time error.
Is the source on the path? If so, if it's newer than the DCU, recompile
For each used unit:
Repeat analysis when loading
For each used symbol ("import": type, variable, routine, initialized constant etc.) from that unit:
Is symbol version of import different to symbol found in used unit? If so, recompile needed.
If DCU is not found, source will need to be found and compiled, otherwise compile-time error
The important concept is that of symbol version. When saving a DCU, Delphi calculates a hash based on the interface declaration of the symbol and associates it with the symbol. Other units that use the symbol also store the symbol version. In this way, link-time conflicts caused by stale symbols are avoided, unlike most C linkers.
The upshot of this is that you should be able to add Classes.pas to your project and modify its implementation section almost to your heart's content, and still be able to statically link with the rest of the RTL and VCL and third-party libraries, even those provided in object format only.
Things to be careful of:
Inlined routines; the body of inlined routines are part of the symbol version
Generics; the implementation side of generic types and methods are part of the respective symbol versions
I found VCLFixPack:
https://www.idefixpack.de/blog/bugfix-units/vclfixpack-10/
I used the techniques from this to replace the method I wanted to patch at runtime.
I have a set of compiled Delphi dcu files, without source. Is there a way to determine what types are defined inside that dcu?
To find out what's in a unit named FooUnit, type the following in your editor:
unit Test;
interface
uses FooUnit;
var
x: FooUnit.
Press Ctrl+Space at the end, and the IDE will present a list of possible completion values, which should consist primarily, if not exclusively, of type names.
You could have a look at DCU32INT, a Delphi DCU decompiler. It generates an .int file that is somehow readable but not compilable, but if you only want to determine the types defined, this could be enough.
The DCU format is undocumented, last I checked. However, there is a tool I found that might give you some basic info called DCUtoPAS. It's not very well rated on the site, but it might at least extract the types for you. There is also DCU32INT, which might help as well.
Otherwise, you might just have to open the file with a hex editor and dig around for strings.