Fr0sT.Brutal

Yeah, field generation will be painful. I got rid of table fields in design-time but assigning grid columns manually really annoys. Luckily it's not the frequent task. Anyway the alternative could be some kind of pre-build/post-build processing that would remove connection properties from DFM and restore it back.

Familiar issue... I avoided it by clearing any connection requisites from design-time properties. Also ensured no admin login will occur in binary for the price of ability to query data in design-time. If you need that, you can add special check in the code: if connection is active in FormCreate, then throw exception. You won't leave such alert unnoticed. More smart option is to add this check to build script if you use one so that it won't produce binary unless you turn connection off.

MS does really good job keeping backward compat but sometimes they just break things, just like it was for CreateProcess that started requiring the string to be mutable. I suppose usage of CreateProcess is MUCH larger than reading hInstance as starting point of the module image. So - everything is possible. But currently the solution is usable

Autoupdate is evil and autoinstalling fresh MS updates until they're tested for at least a month is like jumping from the roof in hope there will be a haystack below.

Tesseract is open source and seems to support Android https://f-droid.org/ru/packages/org.totschnig.ocr.tesseract/

Yep but the fact must be documented or it could change without notice Damn, I searched in GetModuleHandle and LoadLibrary but forgot about the description of the type itself. Thank you!

This would be cool but I haven't found any mentions that HInstance is in fact a pointer to module in MSDN.

Yes but you still have to find where to start from.

Try to find the exact issue by tracing actions. Here you have : querying data from DB, loading BLOB to stream, loading from stream to BMP, loading BMP to image. Check which one of them fails

Sounds interesting. Another issue that could be solved more easily with this feature is inability to build some unit deep in dep graph. Now compiler just throws error "cannot compile used unit" at position of project's main uses section leaving the task of searching the trouble unit to you.

If by "correctly written" you mean "the one that had foreseen all features MS and Emba and whoever would introduce in nearest 10 years" then no, this won't be a problem. ASLR breaks things if an app needs to know its internal layout and MS haven't provided an API to know current base address (at least I know none).

That's likely the case. I guess they already have regretted thousand of times for enabling this feature by default

Hmm, so you have encrypted Delphi exe and unencrypted Delphi DLL? I hope no runtime packages involved? Anyway the answer remains the same - protectors hook into normal loader mechanism so their devs are the 1st to ask.

Make minimal reproducible sample and send it to Wibukey support. You paid them money, let them do their job

I suppose these issues are not a concern in case of console window?

Just remember that process IDs are not monotonic and could be reused if a process closes and another one starts. @robertjohns are you trying to protect from launch under a debugger?

I'd go with mysqldump if it doesn't have built-in service controlled via remote calls (like Firebird has Service API).

Ah, sorry, didn't notice FMX requirement.

I approached to localization just now. From what I read the most recommended way is to have all string constants in resourcestring sections and change them through hooks and resource magic. Okay. But I also have many constant arrays type TErrCode = (errThis, errThat) TErrMessages = array[TErrCode] of string = ('This', 'That') How is best to have them localized? The only option that comes to mind is res... SErrThis = 'This' SErrThat = 'That' TErrMessages = array[TErrCode] of string = (SErrThis, SErrThat) Another is have them translated when needed: ShowMessage(_Loc(ErrMessages[ErrCode]) But it will cause more brackets and is vulnerable to forgetting.

Well, finally I translated the app. No hooks involved - just my functions. Luckily I have most of units using base unit where I placed the localizer. Alas, translation is possible only once - changing on-the-fly is not nesessary and it requires too much boring things like thread safety, reinit of controls and so on to implement it just for the case. I also implemented that overwriting of constant arrays. As a conclusion: resourcestrings are cool idea allowing completely transparent substitution. And it's a real shame this mechanism couldn't be customized without Windows-only memory hacks.

I use EhLib

Main reason of this redeclaration magic is not to have to install descendant component with all that boring stuff of building a package, registering unit, adding components to palette, renaming all existing components and so on.

I know that. But OP wants the app to be modern, he doesn't require the dev machine be modern. I'm saying that even very old Windows + Delphi produce apps running fine on modern Windows. So using modern IDE on W10 easily allows to produce apps running on W11

I have apps built with D7 on XP running OK on W10

Plenty of them, check the list in my signature