Angus Robertson

SVN has been updated with several changes to the private key signing and verifying functions, it will be zipped later tonight. All the functions that sign and verify data digests with private keys now have a new EcdsaIEEE Boolean flag that specifies Elliptic Key ECDSA signatures are the shorter IEEE P1363 digest that many applications expect instead of the longer ASN.1 digest OpenSSL generates. The Jose sample has a tick box to test all these functions. I did not use your C++ code since it only worked with one size EC key, and I also need conversion backwards for verify. Currently, the 521 bit keys fail, no time to fix this week, they are strange being uneven length. I found this bug seven years ago when writing the Jose code, but never got around to fixing it, Google searches since bring up the real problem. Actually, the real problem is OpenSSL documentation, that still does not mention IEEE digests for ECDSA. So ICS can now use Elliptic Curve keys with Let's Encrypt, much more efficient than RSA. Angus

You are trying to use events in an unusual way, without any classes. For console applications, it is best to create a class in which you use and create ICS components, just as with a GUI. Look at the sample OverbyteIcsConHttp;.dpr which creates TConApplication = class(TComponent) with the REST component and it's event. Angus

Tour main problem is using TWSocketServer for UDP, it does not work since UDP has no connections or clients. The component might have worked with UDP 20 years ago, but not today. For UDP you just use TWSocket. Or use the newer TIcsIpStrmLog component with LogProtocol as logprotUdpServer which is much easier to use, look at the Snipptets sample for very simple examples. Angus

I'll fix it next week, Angus

There was a new property ResponseNoException many years ago, but the default only changes for the next release, since I kept forgetting to set it. May 21, 2018 V8.54 Added ResponseNoException property to suppress error exceptions for sync requests, ie most 400 and 500 status codes (eases debugging). Jul 16, 2025 V9.5 ResponseNoException now defaults to True to skip exceptions for most connection errors like 404, etc. Angus

So which defines have you changed? As I said, you can set GSSL_PUBLIC_DIR to your own directory, which won't be created if it exists. Not creating it on startup will add a lot of extra checks to the code. Angus

ICS does not put random files into that directory, it extracts the OpenSSL DLL files there, as explained in the readme9.txt file. Using a common directory, means all ICS applications share the same DLLs, unlike a couple of years ago where ICS applications typically had DLLs in multiple directories that were a pain to update for new versions. If you are not using OpenSSL, don't include that unit. If you are using OpenSSL and don't want that directory or prefer to specify your own directory, the readme explains ways to change it, but these are not extensively tested or used. You will then become responsible for distributing the OpenSSL DLLs, somewhere. Angus

None of the functions relate to the ICS library, never heard of WP Tools. Angus

I don't see any references in the Delphi WinApi. Windows unit to winsock2.h, except as a single comment. But there are lots of $HPPEMIT defines bringing in other files like wintrust.h, so I guess that is how winsock2 comes in. At least the problem is fixed, for now. Angus

Why did your project include winsock2.h? ICS applications should not need any winsock literals or types, others than those defined in OverbyteIcsTypes or other ICS units. Angus

Perhaps the July change forced C++ to rebuild header files for the ICS components? So your C++ TCP servers are now behaving correctly? As I've said before, my understanding of how all this works is zero. Perhaps old headers should be deleted when packages are built, maybe that is what experienced C++ developers do, but that information needs to be fed back to me, so I can fix the root cause. Angus

CF_ACCEPT and CF_REJECT were only added to ICS this July, I'll rename them to avoid any conflicts with C++ header files. But it probably brings us closer to the problem. If you include C header files that diverge from the Pascal conversions we use, a mix of Delphi RTL and ICS own versions, conflicts might arise, ideally flagged by the compiler as in this case. The RTL conversions are rarely updated for new APIs, the Win services unit is missing stuff added 20 years ago. And since ICS has to be compatible with Delphi 7, we need our own anyway. Angus

doSocketLocalClick has both a client and server, you only need the server code. But it's very similar to OverbyteIcsIpStrmLogTst so may not help you get closer to the real C++ problem. Angus

The Snippets sample has two simple examples of using logprotTcpServer mode. Did you the compiled sample work OK as a sample? No idea why it fail would from C++. Angus

Sorry, it's a reference not everyone can access. Angus