Fr0sT.Brutal

Well, MS had a good bicycle but when someone needed to cross a river they advised to swim on it. No surprise things gone bad.

Thanks! I talked to my colleague and he told that that project is working OK, he managed to get things done. But now he's aware of your fix and will decide if he needs it I see. Child sends message to parent and parent occasionally sends message to child. Oops!

I believe these functions should be there right from the 1st Unicode version shouldn't they? Anyway their presence could be checked by $if declared(LocaleCharsFromUnicode)

You're able to modify clients? If yes, use TLS and check certificates of both server (at client side) and client (at server side), ensure certificate corresponds to server host and, for the maximum security, add auth by login-password

Ah, that's it. Thanks, I'll take a look

Where? I can't see it neither in branches nor in tags 😞

With this I fully agree. However, what if we step further to the rabbit hole and place a bg-thread-owned control into a main-thread-owned one? In theory this shouldn't raise issues as long as all interaction is done via Send|PostMessage. And if we desperately jump into the rabbit hole, we can recall TWinControl.DestroyHandle/CreateHandle that allow to transfer an ownership on a control between threads. Of course this is really bad practice but what if there's nothing else you can do. F.ex., my colleague has project which periodically generates charts with thousands of points and exports that to image. And the main UI has to be responsible while generating. Alas, TTeeChart is visual control so he has to use such bad practice creating it inside bg thread.

Ahh, the main issue is that OpenSSL's lib1 uses lib2 via hardcoded name not the Delphi unit ?

Could you please clarify? Is it all about lib filenames? Won't renaming OpenSSL lib files to, say, libeay_internal.so with appropriate change in units help?

Why prevents? I underscore - we're talking about a control fully isolated inside a non-main thread - this means it has no parent window belonging to another thread of the app. With pure WinAPI window and bg thread running message loop, what issues could arise when talking to that control from main thread only by messages? Fair point. However, if this procedure is executed only as reaction to WM_PAINT that is only launched by WndProc, seems it couldn't be interfered because WndProc calls seem to be serialized by OS. Though MS docs don't clearly say so (they only state SendMessage directly calls WndProc) my test shows that while WndProc is running, SendMessage's from another threads just wait for it to finish. I could be wrong here but I want to know what exactly makes WinAPI thread-unsafe.

Similarily, you can have a strong belief that banana is fruit but that will not change the fact that isn't. How about proofs? My position: as long as communication to WinAPI control is done via Post/SendMessage (which is the 99% of cases), it is thread-safe. Your move.

No it wasn't. I consider WinAPI UI pretty thread-safe.

Just generate SQL in code basing on your structure, pattern is like select * from (select count(*) as cnt1 from DOWNLOADS where CHAR_LENGTH(REMPATH) > 60) join (select count(*) as cnt2 from DOWNLOADS where CHAR_LENGTH(LOCPATH) > 50) on 1=1 join (select count(*) as cnt3 from DOWNLOADS where FSIZE > 50000) on 1=1 (names are from my test DB but you should get the idea)

It could be easily checked as all these forks are visible and the message in the header usually says "fork behind master by N commits" or "fork is up-to-date with master". Moreover, filtering by "Active" repo type (with push activity) in https://github.com/pjde/delphi-mqtt/forks produces only 4 items that are easy to check (switch to list view to have filter and sort actions)

Even for 10.4.2 MoveFast is far not fast 🙂 Anyway, great news! These functions are the cornerstone of most apps, nice to see them improved. I wonder what about Linux? Asm versions are Windows-only.

Why not? It is built on thread-safe message queue. Talking about VCL, if a component is hanging in the air (without a parent), not using globals like Application and Screen and not touched concurrently there's a chance it could be handled in bg thread.

F1 🙂

Doesn't Android have OpenSSL built-in?

.superdupersecure 🙂

type TSomeProc = procedure of object; TForm private procedure DefProc; public NullableProc: TSomeProc; end Form1.NullableProc := nil; Form1.NullableProc := @DefProc;

My thoughts... 1 - don't need 3 apps, just unite service and console into one 2 - type of IPC depends on your needs: - STDIN/OUT are the simplest and x-platform but only if an app works in request-process-reply sheme. Pipes as they are will make apps stuck (writer if the pipe is full, reader if the pipe is empty). - Async STDIN/OUT pipes are more complex and probably not portable (or require porting to all platforms). They have nice "pro" of zero-conf (if a worker app is launched by another one, the launcher already knows the handles) or, in the case of named pipes, could be identified with a constant name. - Sockets are the most powerful and could be async but they have to occupy a port to listen which both sides must be aware of. In the case of one app launching another the port could be left to OS to decide any and launched app could report the actual number to STDOUT.

I usually keep long texts in resources as RCDATA but extending the limits would be nice...

Memory table? I believe all serious DB-aware libs have it. However, clientdataset sample looks nice as well. It now is able to store data? Last time I touched it it was just a dataset API wrapper requiring many boilerplate code to function

One of useful applications I see: Q: - write unit tests for function SplitString that cover all possible cases A: - Here is an example of a unit test for this function that covers all possible cases: procedure TestSplitString; var arr: TStringArray; begin arr := SplitString('abc,def,ghi', ','); Assert(arr[0] = 'abc'); Assert(arr[1] = 'def'); Assert(arr[2] = 'ghi'); arr := SplitString('abc', ','); Assert(arr[0] = 'abc'); Assert(Length(arr) = 1); arr := SplitString('', ','); Assert(Length(arr) = 0); arr := SplitString('abc,def,ghi,jkl', ','); Assert(arr[0] = 'abc'); Assert(arr[1] = 'def'); Assert(arr[2] = 'ghi'); Assert(arr[3] = 'jkl'); end; This test verifies that the SplitString function correctly splits a string into an array using a given separator, regardless of the length of the string or the number of separators present. == Somewhat awkward but with some adjustments could simplify the most boring task. Btw, the function itself was written in the most dumb and non-optimal way I can imagine 🙂

As Dorian said: