Fr0sT.Brutal

Well, that's your decision of course but I'll be very sad if you do it. Tons of applications still use plain sockets and if you look at other languages, they always separate plain and TLS: NodeJS, C#, Go lang, Rust, Python...

Noticed bugs (version is 8.71): 1. include paths for DXe7, 8 packages (attaching fixed files) 2. unit OverbyteIcsZLibObj is still included unconditionally into all packages regardless of USE_DELPHI_ZLIB value. It should be either placed under condition or made empty when USE_DELPHI_ZLIB is defined (just like with SSL) OverbyteIcsDXe7Design.dpk OverbyteIcsDXe8Design.dpk 3. In /Include/OverbyteIcsDefs.inc: { Uncomment next line to always include SSL code into the binary. } { In most cases leave it commented and define USE_SSL in the project options } { if required. } {$DEFINE USE_SSL} I suppose either comment should be modified or define commented (the latter is better!)

The subject is flaw in Delphi's FireDAC, online SQL tests are irrelevant

Then I'd consider it a bug. DB object names could be any as far as they're quoted. It's annoying to be unable to turn off the macro stuff. If you can't wait for a fix, the only option left is to use macros. You can even automate substitution and pack it into a single procedure to keep clean code.

Okay, we're getting closer. So your team fully develops these scripts and no customer has access to them? Then just compile these scripts into binary and protect it from modifications by signing. Next, why Python? Had it been chosen for its rich packages set because processing is pretty complex and implementing all required stuff would be huge task? Otherwise you can use PascalScript engine and build it yourself removing potentially dangerous operations. The same you can do with P4D or any other script engine (JS/Lua/etc) but it will require some investigation and C knowledge. Moreover, what forbids you from writing DLL's for each processing?

My advice was to try {id <identifier name>} Expands to DBMS-specific quoted identifier syntax. For example: {id Order Details} -> “Order Details” on Oracle.

These details don't help much. Do you just have many implementations that are maintained by your team or each customer should be able to modify them? What features you need to expose to script engine? What so horrible happens if someone modifies a script according to their needs, estimated they already have your app running on their machines under their full control? Anyway if the security is SOOO strong, do you really have rights to make such fundamental decisions on an important part of the app? I suppose there are some architect guys responsible for app structure and features. You also haven't mentioned what architecture your app has. Local only, customer-personal client-server, shared client-server? Are scripts supposed to run locally or on a server? I wouldn't bother at all if scripts are to be run locally and if they don't able to bypass any access right checks (by accessing opened DB connections from an app, for example). There's no difference between running such a script from your app or from a standalone installation.

Won't this help https://docwiki.embarcadero.com/RADStudio/Sydney/en/Preprocessing_Command_Text_(FireDAC)#Escape_Sequences ?

Funny, just yesterday I fought with bugs in the same area. I used Halt as well but it failed to terminate the app when called from main form's OnShow

Those who use it to break through blocks on their side will say many "thanks"

Then it's easier to store whole scripts inside exe. Script signing seems more interesting (allowing versions, limitless number of scripts and so on).

$ is pretty common in Firebird as well (for system tables). Maybe \$ or $$ allow to bypass macro substitution?

If you specify what exactly you need, you can get more useful answers instead of crystal ball guesses

Just guessing - is there a property like "macro char" which is "$" by default?

Why you mess with attaching a console? It is attached automatically by OS. I have no issues: library Lib; uses System.SysUtils, System.Classes; {$R *.res} procedure Log; begin writeln(TimeToStr(Now)); end; exports Log; begin end. program Caller; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, Windows; var LogFn: procedure; hLib: THandle; begin try hlib := LoadLibrary('Lib.dll'); @LogFn := GetProcAddress(hLib, 'Log'); LogFn(); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; readln; end. Output is visible for both direct run and run via cmd. As a side note, this kind of logging seems non-optimal to me. It's more adaptable to let caller set logger callback function so that output could be anything.

If you only want your scripts unmodified, that's one question (check hashes, OS-level protection etc) If you want to defend against any potentially malicious script - that's another one (sandboxing, modified executor etc)

They never care about older versions as soon as a new one is released. They don't even make bugfix patches, not talking about feature backports

Or Google translate 😄

I init records where possible, just as with any variable. Fields tend to be added, and I was hit several times with newly added fields containing garbage.

Yes, they have disadvantages. Probably base class will fit your needs more

So it claims Arnie is not living??? 😞

start async repeat check if async finished until timeout elapsed

We do our communications via Redis. It also has pub/sub, groups and plenty of features we don't use. It also can store data in a file so reboot won't cause loss of records. Communication via sockets. One thing to add, it requires Linux machine. As a general hint - encapsulate transport level into a generic interface and don't bind to concrete tech throughout your code. This way changing the transport will be just a question of modifying a single unit (App tethering seems like nice example of this approach)

From what I've read about ASLR, addresses could be any even without additional options. And even without ASLR you can achieve 64-bit pointers by occupying all 4 Gb RAM (swap file should be disabled). Btw this is pretty good test for valid pointer operations, especially estimating huge heap of legacy 32-bit code with quite desperate pointer<=>number manipulations that was converted to 64-bit but probably never thoroughly tested

In addition to native libs there's very powerful opensource ImageMagic project that could be called as lib or an external app.