Leaderboard

Hi, when you read the title, you probably already had the standard answer in your head: "Does not work with Indy, supports only OpenSSL 1.0.2 at most and thus no TLS 1.3". I can reassure you, that is not my point. Or actually even more precisely: That is exactly my point 😉 I've spent "a little" time writing the Indy support for OpenSSL 1.1.1 and TLS 1.3, and added a push request to Indy: #299. At the same time I have fixed a few issues that have been posted to GitHub (see PR). I wrote 2 new IO handlers ( one for server and one for client), the old ones are unchanged to avoid conflicts. Everything was written and tested in Delphi Berlin 10.1.2 on Win32 and Win64. I have neither macOS nor iOS nor Linux nor Android, nor FreePascal, nor older (or newer) Delphi versions. I have tried to keep older Delphi versions in mind to ensure that it will run on them, but there have been no tests on my part. I have tested it extensively in small test applications with other servers/clients. In addition, I built it into a large Real World program with TCP server/client, SMTP/IMAP/POP clients, FTP client, HTTP client, and it also ran there without problems. Unfortunately the nice man, who has provided new binary files of OpenSSL under indy.fulgan.com has said that he does not offer versions > 1.0.2 anymore. So I used the versions of slWebPro in the beginning (they even still work on WinXP), later I used the versions of Overbyte, because they do not have any external dependencies (and are digitally signed, but no XP anymore^^). But both worked without problems. All files are located in the subfolder "Lib/Protocols/OpenSSL". There are also subfolders "static" and "dynamic" which offers quite extensive imports of the OpenSSL API, once for static linking, once for dynamic loading/unloading. For dynamic loading there are also possibilities in the "IdOpenSSLLoader.pas" to trigger the loading/unloading itself, if you need the API outside of the IO handler (e.g. for your own x509 generation). To save me the double writing of the imports, I wrote a kind of intermediate code in the folder "Intermediate", which I let generate with "GenerateCode" to the two variants. The tool "GenerateCode" is only a simple string customization and actually only designed for Berlin, so I didn't bother about downward compatibility. As a normal user of the IO handlers you don't need them, only if you make changes to the API implementation. So and now comes your. It would be nice if one or the other would test this, so that it is not only WOMM certified, but can withstand more real situations. For me it also works with the Indy, which comes with Delphi Berlin, when I create another unit, which provides some new Indy types and functions. Of course some units have to be adapted locally to use the new unit.

I think it's pretty clear: You need a license per developer, not per end user:

Oh. This again. Surely your users can just make the the icon appear always if they want to. Perhaps they don't want to.....

Yes, please - please send a pm. we do have a technical connection to the German counterpart of this forum to make sure that a “Lars Forsdal” in the English forum is the same person as in the German forum. this is the reason we are limiting the changes of usernames. So your new name must be available in both forums - even if your are just registered here.

In my work there's rarely a difference. I have a lot of clients where the job boils down to "our code sucks - fix it". The problem is often the complete lack of a framework - or a badly designed one. Yes! In my work process I usually refactor and redesign iteratively, continuously changing stuff toward a distant goal while making sure the new code still works. In the beginning the size of the code and the complexity grows as the solution now contains both the old mess and the new solution. Then at some point it's as if the junk suddenly evaporates and I'm left with amazingly little code. Always a good feeling.

Okay let's go deeper. You intend to use custom TCP. So you have to implement both sides (client & server) of it, develop message format, likely including auth & encryption, different request types (get list, put file, ...) and so on. Of course that's possible and not that hard but seem useless in your case. Sure TCP won't go away I was talking on FTP only. Well, it has some design problems (two channels f.ex.) and for some reason more and more servers drop it in favor of HTTP. HTTP is implemented with system-native components which means you won't bother with custom SSL libs and it's pretty powerful protocol that is able to do all things you want. If you mean completely serverless solution then probably any TCP-based protocol won't fit your needs, maybe you'll need UDP multicasting.

I stand by this post It is not possible as it is not what Microsoft wants you to be able to do. Anything to achieve this goal is a hack that may or may not cease to work after the next OS update. It is a waste of time and money. So just stop pursuing this and ask your users to set it manually. Write it in your manual, or some MessageBox, and also mention that you can not support any installation, where this is not set accordingly.

Against my better judgement I'm going to bite. Below are screenshots of the "CPU time" and "Peak working set" columns in Task Manager after a single benchmark run of the Fastcode Memory Manager Benchmark & Validation tool. It includes a variety of tests, including replays of memory usage recordings of real world applications:

Thank you to all that have provide a feedback for my first test example. Remember that I was ask to show evidence that FastMM5 scales better than FastMM4. I think there we agree that this is shown. The sample was actually not provided to be a full scale compare of to other memory managers. But of cause it was used in that direction (I would have done that as well ). Concerning the difference to ScaleMM we will for sure go into more details (I still hope to see similar jumps as well in x64) Like with a "good Formula1 car design" we are convinced that we can easily improve step by step while keeping all the features as "memory leak check", "FullDebugMode" etc. Concerning IntelTTB we will have to run some "full scale compares" to see in which real world cases we do have a clear difference (and why). regards Günther

Use a different memory manager then. You don't have rights to other people's work. Do I have rights to your work? What on earth are you smoking?

[facepalm]

I would expect so, but I don't know for sure. I do know that when using HeapCreate / HeapAlloc this is true, but that's no use to you. I do have a NUMA machine to hand and would be happy to run some tests on it if that would be useful for you.