Leaderboard

I agree, but what means seriously outdated applications - all MDI applications and Delphi IDE? 😉 No, it should be an additional item in the DPI awareness drop down box. I called it "System Aware (enhanced)" - but I see it makes it clearer if it is named "GDI Scaling". Delphis DPI Awareness modes and its Manifest entries would then look like (simplified):

I prefer that people link to the original source and/or describe how to collect the appropriate set of binaries from the official sources, rather than "republish" them. There is a staggering amount of malware out there, and you may call me paranoid, but the fact is that convenience is not a good reason to download binaries from unverified sources.

As you can see here: https://github.com/andrea-magni/MARS/blob/f3c2396eeac4df9b1f9a4d4ef640d95bb6dd569d/Source/MARS.Core.MessageBodyWriters.pas#L217 It is a really straightforward implementation and I guess yours is not much different. The StreamToBase64 and StringToStream functions are also available just in case you need them. Let me know if there's anything I can help with! Thanks, Andrea

Not being a native English speaker I just looked up what "deprecated" actually means and it turns out that it's just what you describe: Discouragement of use. My bad.

You can call it whatever you like, but if the fact that MS didn't bother to update MDI window style to match their latest (now 5 years old) Windows 10 OS does not qualify as being deprecated, then I don't know what deprecated is. Also MS is spreading that FUD for the last 25 years...

@emailx45 it will not work for new project or existed but without *.dsk file. I asked about it here:

Multiple Document Interface - Win32 apps | Microsoft Docs In practice we can see that MS have not updated MDI for a very long time. The window chrome for MDI child windows does not match the latest style. I mean, this is MS, it's not going away any time soon.

Another set of binaries... Am I the only one that is completely allergic to binaries from unknown sources?

Here are some timings: sorted reverse half random QuicksortInteger(1000000): 0.05787 0.06269 not done 0.16328 QuickSortPlusInteger(15)(1000000): 0.04744 0.04995 0.24928 0.14548 TimSortInteger(1000000): 0.00214 0.00252 0.00981 0.16411 QuicksortString(1000000): 1.36692 1.00144 not done 1.16640 QuickSortPlusString(15)(1000000): 1.38534 0.99298 0.81605 1.23809 TimSortString(1000000): 0.06285 0.09036 0.16268 1.86726 Sorting 1 million integers or strings respectively. The strings are simply generated with IntToStr for numbers 0 to 999,999 and compared with CompareStr. This means that Sorted, Reverse and half for strings is not really correct, because '10' < '2' etc. I need to fix that, but this is not too bad a dataset for sorting tests either. (I just googled and found that apparently there are some test datasets for sorting algorithm performance. I'll have a look into that.) The numbers are the time in seconds for a single run on my computer. As you can see, TimSort is faster than all of them with the exception of random data, where it is still in the same ballpark. The test program is in the subdirectory Tests\SortingTests. Please note that with the exception of TimSort, these sorting algoritmms are not implemented for best performance but for convenience: They are abstracted from the data and use callbacks to compare and swap items. TimSort currently works directly on the data and uses a callback only for comparison, but my goal is to abstract the algorithm from the data in a similar manner, if possible.

If you're interested in another alternative, I've started from the root document to make a pure-Delphi version under a permissive license: https://github.com/stijnsanders/tools/blob/master/crypto/aes.pas I also did HMAC and PKDF2 here

You are right, SynCrypto is fine with FMX running on Windows - and it uses RawByteString or TBytes as required since Delphi 2009. But it is not a OS compatibility problem - it is a compiler issue. To be fair, it's Delphi cross-platform compiler/RTL which is designed poorly, especially all the backward compatibility breaks they made about strings and heap. Their recent step back is a clear hint of their bad design choices. There is no problem to use SynCrypto on Windows, Linux, BSD, Darwin, for Intel/AMD or ARM 32-bit or 64-bit CPU, if you use FPC. But we didn't lose time with targets breaking too much the existing code base. I am happy I didn't spend weeks making mORMot ARC-compatible - which is now deprecated! - and focused instead on FPC compatibility and tuning. Which was very rewarding.