ap2021

Fair enough, still a shame to see a good advise go to waste...

Angus, Just wanted to add that fundamentally, sometimes you need to process actual text strings (ANSI or not) and sometimes binary data and it would be nice if this distinction was immediately obvious. It's a universal semantical headache, and C++ has the same problem, because there are just so many data types available and they may all look the same and essentially do the same thing. For example in OpenSSL, there are such function declarations: int EVP_DigestVerifyInit_ex(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx, const char *mdname, OSSL_LIB_CTX *libctx, const char *props, EVP_PKEY *pkey, const OSSL_PARAM params[]); Here, mdname is semantically a string. So it can be / actually is 0-terminated and with no size needed separately, hence pansichar is the correct type we should use in translated Pascal definitions. Unless we know for a fact that the target function expects and can handle Unicode text in UTF8, then we must use putf8char datatype in the tarnslated definitions, or it would cause problems, unless additionally typecast. But here: int EVP_DigestSignUpdate(EVP_MD_CTX *ctx, const void *data, size_t dsize); The data parameter is semantically binary data - they are trying to convery this by using the word "data", there's also a requirement to pass in the size separately and they are trying to use a different data type for it, not just "const char *" (which it could have been, interchangeably), but "const void *". Sometimes, in exactly same way, they may use "const unsigned char *" type instead, but that's because they are just as confused about it as we are in Delphi: __owur int EVP_DigestVerify(EVP_MD_CTX *ctx, const unsigned char *sigret, size_t siglen, const unsigned char *tbs, size_t tbslen); In fact they may have interchangeably used "const char *" for the same data in odd places, because apart from the semantics, it would achieve the same result and if the original developer was tired or lazy, the type used may not reflect its semantical significance. Besides, C++ has no special data type for binary data, so this issue has no silver bullet solution in C++. This confusion then spills over into all other languages and then you translate it in your code, without regard to semantics, as: EVP_DigestVerify : function(ctx: PEVP_MD_CTX; sigret: PAnsiChar; siglen: size_t; tbsret: PAnsiChar; tbslen: size_t): Integer; cdecl = Nil; { V8.52, V8.64 corrected declaration } using PAnsiChar type. This may have been acceptable in Delphi 1 days, but today we have a better data type we should use instead: TBytes. You do not want sematics to be lost in translation, although the original semantics may need to be deduced first, because in C++ it may not be very clear. These functions should be declared in Delphi with TBytes type instead, i.e.: EVP_DigestVerify : function(ctx: PEVP_MD_CTX; sigret: TBytes; siglen: size_t; tbsret: TBytes; tbslen: size_t): Integer; cdecl = Nil; { A future version, properly corrected declaration } or EVP_DigestVerify : function(ctx: PEVP_MD_CTX; const sigret: TBytes; siglen: size_t; const tbsret: TBytes; tbslen: size_t): Integer; cdecl = Nil; { A future version, properly corrected declaration } Which is essentially the same for the operation of the function, but is semantically much clearer and 1) allows Delphi to enforce the type and avoid any internal conversions, 2) will directly accept TBytes parameters without resorting to very frequent PAnsiChar() typecasts and 3) will keep it much clearer to the user/coder. For instance, this will allow you to avoid weird conversions like these: function IcsAsymVerifyDigest(const Data, OldDigest: AnsiString; PublicKey: PEVP_PKEY; HashDigest: TEvpDigest = Digest_sha256): Boolean; begin Result := IcsAsymVerifyDigestTB(IcsStringAToTBytes(Data), IcsStringAToTBytes(OldDigest), PublicKey, HashDigest); end; And will allow you to get rid of AnsiString and AnsiChar parameters, at least the majority of them. With some thought before changes and some testing after, it would really clean up this mess. It cannot be blindly applied to any such translated datatype, each function will need to be looked at separately to figure out the underlying meaning of the type used. But again, perhaps it does not have to be applied to all declarations at once, you can start with a handful of these functions, either picking the ones that you use, or care about or those that may seem easier and then roll it out to others at will. Also, for Delphi, PAnsiChar literally refers to "0-terminated strings", which causes it to drop parts of data after the first #0 it encounters, when it's doing internal conversions, those we do not see and do not expect, therefore introducing hard to troubleshoot bugs. Does this make sense? Do you agree?

I guess an even easier fix would have been to define Smtp DefEncArray with pansichar in the first place. Angus, please add it to your list. I can confirm that Olli73's solution works.

Many thanks, that was indeed the solution! Wunderbar!

Just set the DefaultEncoding property to smtpEncBase64. The text is fine, it just gets BASE64-encoded and then never decoded by the mail client. TSslSmtpCli works with normal UTF16 strings and theres very little stuff going on outside of it, so there are no character conversions that I can see and none that I do, all text I tested so far was just plain English.

Oct 13, 2024 You should get rid of those ansistrings in all callable routines and do the conversions behind the scenes if you must.

Interestingly enough, this "fix" broke it for me under Windows. The fix for which, was to just use TB version. Ansistrings are unpredictable now, Delphi supports them reluctantly and there are probably unwarranted conversions going on under the hood, somewhere, using pansichar's.

Trying to send an email (through ICS), but getting it BASE64 encoded. The Content-Transfer-Encoding header on the message is set to just a single letter "b". Looks like the encoding is messed up somewhere, but it's all ICS vanilla code, all I do is call the SslSmtpCli object and have a callback to perform the steps. Also, I think it used to work for me before. Were there any breaking changes there recently? PS: Changing the DefaultEncoding to smtpEncQuotedPrintable, for instance, sets that header to "q" and the message contains some garbage.

Does ICS offer anything to create ISAPI modules or filters for IIS? MS warns that "HTTP.sys isn't compatible with the ASP.NET Core Module and can't be used with IIS or IIS Express.", therefore there may be compatibility issues there. In my scenario, I also intend to run this on a Plesk-managed server, which offers full remote management for IIS, as well as setting up free Let's Encrypt certificate and automatically renewing it every 3 months - this latter is my main reason to use this IIS setup and not http.sys. If I can reproduce it with ICS components, I will certainly try.

It's just convenient sometimes, that's all. PS: Manually removing multi-platform garbage from DPROJ files in Notepad has now become almost mandatory. I started doing that because a) all that did not make any sense there and b) it was wasting space, but now it's easy to see how that garbage is actually causing problems.

So am I, pirated it on floppies too. And you are just being rude. I have not only described this issue perfectly, I have also provided 3 easy reproducible test cases, 2 of which exhibit this issue and 1 does not. Anyway, it boiled down to the multi-platform garbage DataSnap wizard adds to the DPROJ. And _manually_ removing it, fixes this issue: after that, all ICS components become available. So while yes, it's a Delphi problem, you should document it on your side as well: without this knowledge, ICS is not easily usable in DataSnap or DLL projects. And it is a manual DPROJ editing task, there's no GUI for that in IDE. I should probably advertise a class on how to do that 😉

Angus, my test case is to create a new DLL project, add Data Module and try placing any ICS controls on it - very few show as available. There's something about Libraries that ICS does not like, it would seem. Is this what you would expect? Or anything you can change? The same happens with projects created by DataSnap WebBroker wizard (targeting Windows/IIS ISAPI). But remarkably, a Windows/ISAPI projects created by IntraWeb wizard do not have this issue: I can see and use all ICS components on any of the 3 modules/forms it creates. So, perhaps it's not the fact that it's a Library? It's got to be something else.

Francois, thanks, but you cannot modify this setting from the IDE, it's a Delphi thing, hence half the time you have to manually edit .DPROJ. Sure, it all works, and if I were to redo it all from scratch, I'm sure it'll work, I must still be missing some tiny difference in some file there. I can manually add these components to PAS/DFM and it builds, but it would not display the controls on this one form for me and would pop up warnings along the way. I wish they finally fixed this DPROJ mess. This question probably does not belong in this forum, it has nothing to do with ICS and there's probably nothing you couyld do from your side, sorry for that.

I have 2 similar projects, looking at them side by side, both have a TDataModule-descendant form, but ICS control lists offered are very different. One did not have VCL assigned, I did that manually in .DPROJ and restarted IDE. Both have the same Win32 platform. Switching to Win64 greys out some entries, keeping the same long list in the good project, but in the bad project, there are only 4 controls offered under ICS SSL (and one is greys out in x64). Trying to copy the controls from form to form produces an error: Search path is the same in both. Can this be somehow controlled?

Another very annoying thing under Linux is that ansistring's look Chinese in the debugger: There's no telling what the values are. And typecasting when inspecting values does not work, it would say "ansistring not defined", i.e.: My next hurdle is that it would not load PEM cert: it just cryptically fails. If I were to add "string" vars here, do the assignments, re-run and check the values of strings, then it does show the values. There's of course nothing you can do about that, it's a Delphi bug. But I might write another similar function to use TBytes instead - that would at least show something... Its not permissions, as I ran it as "root" and it was my file to start with. But as it did the validation Ok now, I also know that all shared libraries are fine. Go figure ;-( Ok, never mind, I did figure, no issues now, it loads and everything 😉