Jaska

I use this to make code compatible to previous versions. {$IFDEF VER360} {$IF Declared(RTLVersion122)} {$WARN OVERLOADING_ARRAY_PROPERTY OFF} {$IFEND} {$ENDIF}

Many anti virus software incorrectly flag a Delphi generated EXE as a malware. So they are false positive. Is it so that Delphi is actually used a lot when creating malware or is it that the algorithm that the AV software use are just right. Anyway I am tired explaining customers that the EXE does not contain any malware but this is a false positive. The EXEs that cause these are VCL (30/64-bit) and they are all digitally signed. It does not help too much reporting the AV software because they act too slow and once they register a false positive EXE we already have a new EXE build with a different digital hash. Does anybody know a way to avoid these false positives?

Yes we use DRC files and resource names. I noticed that BTM is forcing to use them. Good choice. I should start doing the same 🙂 This ID shifting is very annoying, but I guess it is very difficult the prevent it unless Delphi compiler starts caching the name-id maps. Now it seems to regenerate them every time in the order it processes each string.

Resource only DLLs are platform independent so the same DLL can be loaded in both 32 and 64-bit environment. However this doesn't solve the problem. It only works if the resource string IDs in both 32-bit and 64-bit EXE are exactly the same. This is not the case on most Delphi application. If you compile the same source to 32 and 64 bit you will see that 1) The amount resource strings differ 2) The Ids of the resource strings differ So you have to build two sets of resource DLLs. One for 32 bit and another for 64-bit

I have a trouble understanding how dlsym works. My goal is to implement binary level localization for Delphi generated MachO (macOS and iOS) and ELF (Android and Linux) files. I have written classes to manipulate MachO and ELF files. Basically what I need to so is to find the symbols for resources (strings, forms and other resources). These symbols point to the resource segment in the file. The resource segment contain all the resources and their lengths. When writing the localized files I generate new resource segment data and then update the symbol values to point to the new address in the resource segment. As far as I know this is all I need to do. When I run the localized application, RTL calls dlsym to get the address where the symbol points. Now here is the problem. I expect dlsym to find the symbol, read the n_value and return it. Using a MachO viewer app I can see that the symbols' n_values have been updated and the resource segment also is updated. Still dlsym returns the old address. The same address that was the original value of the symbol's n_value (that no longer is there because it was overwritten during the localization process). So I believe that dlsym does not get the value it returns by locating the symbol and returning its n_value but there is some other section in the MachO file that also contains the same n_value and dlsym returns that. Is this the case? If it is what is this other section I need to update.

I got this working. In addition of patching the resource data and symbols you need to patch the symbol offsets in the export section of the dyld_info_only part.

I will do both. Just like I have done for Windows

Does anybody know what are the most popular UI component libraries for VCL, These are the ones I have used in the past: DevExpress TMS VCL UI Pack Raize/Konopka Signature Virtual Treeview Any other popular UI components?

Here is an open source API for Delphi to handle plurals and genders. The API uses the industry standard ICU message syntax.

Lars, thank you for your post. It is indeed sad that Markus died. I want to correct one thing in your post. I founded Sisulizer with my brother, Markus and Renate. I wrote the application with my brother (in Delphi, of course). Markus and Renate handled the sales. We shared the support. About a ten years ago I left Sisulizer. I wanted to create a new and better localization tool that would be better suited for IT world heading to the cloud. I did not want to make a cloud only solution like MemSource and Crowdin. Instead wanted to make a hybrid solution that combines the best part of desktop tool and a cloud tool. So I wrote Soluling. The desktop part of that works like Sisulizer. It means you select a file, Soluling scans it, you translate or you let somebody else to translate, and finally Soluling build the localized files. Compared to Sisulizer, Soluling has the following improvements: The app itself is also provided as 64-bit Modern Office style ribbon UI The visual editors use real components. In Sisulizer they were emulated. This means that the translator will see the forms just as they appear in Delphi IDE. In .NET they use the real .NET components. Interactive translation memory with fuzzy matching and an interactive termbase. Sisulizer was loved by developers but not that much liked by translators because TM and TB were missing Support for 6 machine translation engines: Google, Microsoft. Amazon, IBM, DeepL and ModernMT More that 100 supported file formats including Delphi 11 Alexandria, .NET 6.0, Angular, React, Vue, DITA, Android, iOS and databases Command line version, SoluMake.exe , that can be used in build servers and even cloud based DevOps build processes Automatic conversion from Sisulizer's .slp to Soluling's .ntp. It generally takes a less than a day to switch from Sisulizer to Soluling. Soluling comes with open source I18N library that brings a nice grammatical number (plural) and grammatical gender (male/female) support for Delphi and .NET. Sisulizer customers get a discount. Soluling's desktop and command line apps are written in Delphi. Next year we start rolling out the cloud parts that let you push your projects to the cloud where the translators can get them and use either Soluling's desktop app or a browser app.