Leaderboard

Hi everyone, more than twenty-one years ago, I started the German-language part of this forum and could not even begin to imagine what it would become. Thanks to the tireless support of many moderators as well as your thirst for knowledge and willingness to answer other people's questions, it has become a pillar of the virtual Delphi community - even far beyond the German-speaking world. Since 2018, this English-language part of the forum has also been available, with considerable support from Lars. With an online presence of this size comes the obligation to take proper care of it. I have always been very happy to do this, but over twenty-one years is a very long time and life and its priorities change. I can't help but realize that my daily/weekly time has become less available and the time has come for me to hand over the management of the forum to someone else. Thankfully, Thomas B. ("TBx") has agreed to take over the Delphi-PRAXiS and continue it in good hands - together with Lars, of course. You know Thomas as a longtime moderator of this forum and now he will take over my previous role. I myself will of course remain part of the Delphi community - not least because I continue to work a lot with Delphi in my job. I will also remain a part of this forum. Thank you all for over 21 great years!

@Edwin Yip Yes, we will try to make a TLS 1.3 layer beginning of this new 2024 year. 😉

With this new year, it was time to make a mORMot 2 release. We went a bit behind the SQlite3 engine, and we added some nice features. 😎 Main added features: - OpenSSL 3.0/3.1 direct support in addition to 1.1 (with auto-switch at runtime) - Native X.509, RSA and HSM support - mget utility (wget + peer cache) Main changes: - Upgraded SQLite3 to 3.44.2 - Lots of bug fixes and enhancements (especially about cryptography and networking) - A lot of optimizations, so that we eventually reached in top 12 ranking of all frameworks tested by TFB https://github.com/synopse/mORMot2/releases/tag/2.2.stable 🙂

Thanks for the comment, yes record ending is important, since this API has simple URL encoded arguments a single CRLF will be fine. In fact, allowing multiple requests in a single message is probably what is really needed. This client tends to do 10,000 odd requests in a single block during the night, takes about 25 minutes at the moment, single server thread, with a new session each time, eight per second. Will need to decide how many requests can be queued, in case they decide to try 1 million. The responses do include the main argument, ie {"success":true,"reccount":16,"records":[{"number":"118118","number_from":"2010-03-10", etc. I should add the API type to the outer wrapper. Then send them back one message at a time. Either the server or client can ping/pong to keep the connection open, I was planning on the server doing that to avoid complexity at the client, they simply close the connection when the batch is over. Angus

Hi, While having the full HTTP request and including the HTTP header for the response is best for switching between the connections type, you can do this by striping all of that and changing the request to pure and simple JSON ,(like a JSON object with a field called apicmd and its value is codelookup with a second field numhistory ), here i want to point an important thing is to put a separator for this simple API request like one CRLF or double CRLF to indicate the end of the request, same can be with the response, also want to point that is very important and will pay in future to put the request parameters in the response for each request, this will prevent the confusion and remove all the tracking for request-response pairs, web socket allows you to send many request from the client and the server can response when it is ready and doesn't require serialization, some queries might/could be executed on the server different threads but the response always known for the client. Not really important, but i prefer to send one request establishing the timeout and the frequency of the ping to be expected, this way, server have some knowledge on how to handle stale connections, remember that web sockets connection will stale without ping, so the best approach here is make sure the client to ping periodically, and the server will close the connection if this period violated, the ping form the client could be 3 minutes and the server will close the connection on 5-6 minutes if nothing being received in that period(ping or not).

Problem with this is that if the record has any managed types, then they won't be properly initialised/finalised when using GetMem/FreeMem. This is what New/Dispose brings.

Can you see the value if you create a new Watch for it? Is the "variable" you are trying to inspect, actually a function result like MyObject.MyFunction? If it is, you need to go to Tools | Options | Debugger and enable "Allow side effects and function calls in new watches"

Today, almost all computer security relies on asymmetric cryptography and X.509 certificates as file or hardware modules. And the RSA algorithm is still used to sign the vast majority of those certificates. Even if there are better options (like ECC-256), RSA-2048 seems the actual standard, at least still allowed for a few years. So we added pure pascal RSA cryptography and X.509 certificates support in mORMot 2. Last but not least, we also added Hardware Security Modules support via the PKCS#11 standard. Until now, we were mostly relying on OpenSSL, but a native embedded solution would be smaller in code size, better for reducing dependencies, and easier to work with (especially for HSM). The main idea is to offer only safe algorithms and methods, so that you can write reliable software, even if you are no cryptographic expert. 😉 More information in our blog article about this almost unique features set in Delphi (and FPC): https://blog.synopse.info/?post/2023/12/09/Native-X.509-and-RSA-Support

If you are on Windows you can check GetDurationFormatEx in Winapi

This is nothing about salting. @Kas Ob. wrote it fvery nicely: this is because the AES encoding algorithm is a block algorithm by itself: it works on blocks of 16 bytes as input and output. It works only on full blocks, i.e. encoded output is always a multiple of 16 bytes. So you need a way of "cutting" the result without leaking any information. This is known as "padding" the output - PKCS#7 defined the most common way: you output up to 16 more bytes, in which you fill the remaining bytes of your data with the length of your data modulo 16. So once decrypted, you can "cut" back the result into the original size. For some chaining modes (like AES-CTR) there are some other ways of padding with no additional output bytes, but it is less common. My point was: do not reinvent the wheel, or you are likely to obtain a weak safety.

SecondsToHumanReadableString in my dzlib. There are probably others which I am not aware of. I just noticed that you wanted milliseconds support. My function does not support these.

It's been available for Delphi 12 for some time. The "latest" is always located here.

Also, because SetDialogParams() is taking a TTaskDialogParams by value, a copy is made, which will have its own TStringList object, so you must implement the Assign() operator as well to copy the source record's TStringList data to the copied record after it is Initialized: class operator TTaskDialogParams.Assign(var Dest: TTaskDialogParams; const [ref] Src: TTaskDialogParams); begin Dest.CustomButtons.Assign(Src.CustomButtons); end; class operator TTaskDialogParams.Finalize(var Dest: TTaskDialogParams); begin Dest.CustomButtons.Free; end; class operator TTaskDialogParams.Initialize(out Dest: TTaskDialogParams); begin Dest.CustomButtons := TStringList.Create; end; Otherwise, if you don't do this, the default assignment behavior will copy the object pointer instead, causing the copied record to lose its own TStringList object (leaking it) and end up pointing to the original TStringList object, so when the copied record is Finalized then the original TStringList object gets freed, corrupting the original record that was copied from. That being said, there is no good reason to pass the record by value in the code shown. SetDialogParams() should take the record by const reference instead, then no copy is made. Read the documentation, especially the section on "Passing Managed Records as Parameters" : https://docwiki.embarcadero.com/RADStudio/en/Custom_Managed_Records

It is very likely that you would have less issues with interface based class and then you would be able to pass around interface reference without having to worry about memory management too much. If you still want to use record, you need to fix your Clear procedure. You are calling CustomButtons.Free there which will destroy CustomButtons instance and then you would have crash in Finalize which would try to destroy that same instance. You should just clear the list and not free it there. So that memory management happens solely within Initialize and Finalize methods. procedure TTaskDialogParams.Clear; begin CustomButtons.Clear; end; class operator TTaskDialogParams.Finalize(var Dest: TTaskDialogParams); begin Dest.CustomButtons.Free; end;

It would make his project fit on 10 floppy disks instead of 35.

@PaulM117 If size of exe file is important for you, try Upx https://upx.github.io. For my project, Upx made 12MB exe file from 42 MB.

If you care about such things you are totally wrong using Delphi - especially 64bit. It does suboptimal use of all the registers available in 64bit, it produces a crapton of conditional jumps instead of better alternatives that exist for decades, it does not use SSE (let alone AVX) which exists almost as long (except for some floating point stuff), it does zero optimization wrt to loop alignment, it does not restructure binary code so that some cold code does not sit in the middle of some hot code. I could go on, but these are just a few things that matter more if you really care about the least ns squeezed out of your application than some 300K of binary size.