Remy Lebeau

Yes. There are MANY solutions available for cross-platform development. There is FreePascal, for instance. Or Java. Or many other choices. Not really. It is up to you to decide. You know what you need. Use what suits your needs. Every language and IDE has advantages and disadvantages. Do some research on each one then decide for yourself. It depends on the platform, and what degree the OS allows you to directly access hardware. Most direct hardware access on modern systems is restricted to just the OS, so you would have to use higher level APIs provided by the OS or the hardware vendor. No. Pascal can get just as low level as C/C++ can get.

You posted your question on this forum at 14:17:35Z, then you posted on StackOverflow at 14:21:24Z. That is a difference of only 4 MINUTES. These are NOT real-time forums. You have to give people TIME to answer. Personally, I didn't see your questions on either forum until 3 HOURS after you had posted them. Sometimes it can take people DAYS to answer. So please be patient. Also, it is generally considered rude to ask the same question on multiple forums at the same time. It means you consider other people's time less important than your own ("I posted here, but I'm not going to wait around for a response, I'm going to go over there instead").

You asked this exact same question on StackOverflow, and received answers there: https://stackoverflow.com/questions/70394569/delphi-using-resource-in-email-rather-than-image

TIdMessage creates RFC822-style emails. Do note, however, that the TIdMessage.SaveTo...() methods are designed for SMTP usage, and so will escape emails per SMTP dot-transparency guidelines. So, to use TIdMessage emails in other protocols, be sure to use the overloaded SaveTo...() methods provided by the TIdMessageHelper unit, which adds an AUseDotTransparency parameter that you can set to False to disable that escaping. https://www.indyproject.org/2015/07/30/new-tidmessage-helper/

No, unless you do it yourself manually. You are simply using the wrong tool for the job to begin with. TIdMessage is designed for email only, not for HTTP posts. There is nothing in Indy that specifically handles the Gmail REST API you are referring to, so you are going to have to implement it yourself.

The new overloads were added, and the original overloads were deprecated, in XE3.

Known issue, not fixed yet: https://www.indyproject.org/2021/02/10/links-to-old-indy-website-pages-are-currently-broken/

I agree with @Fr0sT.Brutal. UDP is an unreliable connectionless transport, so some amount of packet loss is to be expected, even over a direct cable. The most common cause of packet loss is when the receiver is reading packets slower than they are being sent and so it runs out of buffer space. Until buffer space is freed up, new packets will get silently discarded by the OS. So, check if your reading code is running too slow, or that your receive buffer is too small for your situation. Of course, there can be other causes of packet loss, too (network congestion, outages, etc).

I can't address that without seeing the actual TLS handshake in a working scenario vs a non-working scenario. All that tells me is that your XE is either not actually upgraded to the same Indy version that 10.4 is using, or your XE project is not configured the same way as the 10.4 project. Neither do I. AFAIK, yes.

Then you still have old files lingering somewhere. Or maybe the new LSP server hasn't parsed the newer files. I don't know. It has been a long time since I last did an upgrade. Try using a tool like SysInternals Process Monitor to see what files the IDE is actually touching as it is loading/compiling, maybe you will see something out of place. If you are referring to the DFMs, then probably not. But it probably wouldn't hurt either, as there have been some declaration changes to properties/events over the years, depending on which components you are using. There should have been dcl files produced, too, since those are part of the design-time packages that get installed on the IDE's Palette. Embarcadero doesn't use the default DPK projects to compile the shipped version of Indy. They use their own DPKs, for instance to enable the use of {$LIBSUFFIX}, which Indy hasn't adopted yet, but will eventually. So, getting 5 DCPs with suffixes in their names is expected behavior, albeit not ideal behavior for modern IDEs. Having the suffixes present only becomes an issue when you upgrade between major IDE versions, then you need to update any projects that refer to the suffixed DCPs. LIBSUFFIX was introduced WAY back in Delphi 6 to avoid that. That really won't work when communicating with modern servers on the Internet. SSL v2.0 and v3.0 are dead, nobody using them anymore. And TLS v1.0 is fast being phased out. You really need TLS v1.1 and v1.2 to communicate with current servers, with TLS v1.3 slowly being adopted, too.

I would not call it a "short" delay. It is actually a considerable delay. I can't find exactly when 10.3 CE was released, but 10.2 CE was released 16 months after 10.2 was released, and 10.4 CE was released 14 months after 10.4 was released. Now 11.0 was released 3 months ago and we are going to wait how long for a 11.0 CE release? They tend to release a new CE either after several Updates have been released first, or just-before/long-after the next major version release. Also, it should be noted that even when a new CE version is not released, the CE license expires annually, so you have to keep reinstalling the latest CE every year to continue using it.

Then you are using a VERY old version of Indy and really should upgrade to the latest. Most likely NOT 10.6.2.0 specifically, but some later version of 10.6.2.x, where x was unknown at the time your copy of Indy was compiled. Specifying multiple SSL/TLS versions will automatically enable sslvSSLv23 internally. That is the wildcard that actually handles version negotiation at runtime. You should not be specifying sslvSSLv23 explicitly at all. Makes sense, because nobody uses SSL v2.0 and v3.0 anymore, as they are no longer secure. Don't use anything less than TLS v1.0, but even that is being phased out of modern servers nowadays, so you really need TLS v1.1 and v1.2 as an absolute minimum. If that weren't the case, the other values (sslvSSLv2, sslvSSLv3, sslvSSLv23, and sslvTLSv1) wouldn't be compiling, either.

If you catch a socket exception and discard it, you don't know on WHICH BYTE the exception was raised on, so how do you expect to recover your communications from that? In general, DON'T discard any exception you can't recover from. If you need to act on an exception (ie, to log it, etc), then catch it, but you should re-raise it when finished. Only discard exceptions you can recover from (socket exceptions are rarely ever recoverable, since the I/O state is typically dead/invalid at that point). The most common reason for that (but certainly not the only reason) is when a deadlock occurs while a server thread is performing an operation that is synchronized with the same thread that is trying to deactivate the server. For instance, trying to update the UI from a server thread while the UI thread is blocked waiting on the server to close. Possibly, yes. Indy relies on exceptions for error reporting, and certain exceptions, particularly socket-related ones, are important to tell the server when a client connection has been closed and its managing thread should stop running. So, if you just blindly catch and discard exceptions, the server might not shut down properly. So, at the very least, if you catch any exception that is derived from EIdException, re-raise it, let the server handle it.

That is an unusual thing to do. This is really no better than a try..finally: try ... finally // sends response as json contents Connection.IOHandler.WriteLn(Response); end; But, what if it is the last WriteLn() that raises the exception? Then you try the same WriteLn() again? I would use this instead: try ... finally try // sends response as json contents Connection.IOHandler.WriteLn(Response); except end; end; Though, are you really sure you want to catch an exception at all? You are going to leave the connection in an unstable state. You may as well just let the exception propagate up the call stack uncaught, and let the server catch it and close the connection for you.

For XML? You could try using libxml2 (http://xmlsoft.org), which is a free cross-platform C-based XML parser that has both SAX and DOM APIs, and offers bindings for Pascal.

Don't include sslvSSLv23 with other versions, that is a wildcard the IOHandler uses internally, it is not needed in this case. Also, you definitely should not include sslvSSLv2 and sslvSSLv3 at all (unless you really need them), as those are old and no longer secure. Typically, you should include only the TLS versions: LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2];

Note that you are responsible for freeing the TJSONValue returned by ParseJSONValue(), so you should use a try..finally for that: // parse json JSONValue := TJSONObject.ParseJSONValue('{"cmd":"program.add.text", "txt":"for I := 0 to 100 do"}'); try if not (JSONValue is TJSONObject) then Exit; ... finally JSONValue.Free; end;

Nitpicking: You are leaking every TIdHTTP object you create. You are querying an HTTPS URL, but you are not assigning any SSLIOHandler object to the TIdHTTP.IOHandler property. While TIdHTTP can create a default SSLIOHandler object for you, just note that it only supports TLS 1.0 right now. So, if you ever need to update your code to handle TLS 1.1 or 1.2, you are going to have to assign the TIdHTTP.IOHandler manually. Your FormCreate() is requesting the URL twice. You already have the text from the 1st query saved in your compare variable, so just assign that variable as-is to your TMemo, you don't need to query the URL again until the TTimer elapses. Your Timer is logging when the IP does not change, but does not log when it does change, or what the new IP is.

When exporting your own functions, simply don't mark your original function as being exported from code (via either __declspec(dllexport) or __export), let the DEF file handle the exporting, so you control the format of the mangling. But, for library functions, I don't think you can do this.

You really should not mess with the compiler's mangling settings. If you want to export your own functions without underscores, use a DEF file to handle that: https://docs.microsoft.com/en-us/cpp/build/reference/module-definition-dot-def-files https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files https://docwiki.embarcadero.com/RADStudio/en/Module_Definition_Files https://docwiki.embarcadero.com/RADStudio/en/IMPDEF.EXE,_the_Module_Definition_Manager https://docwiki.embarcadero.com/RADStudio/en/MKEXP.EXE,_the_64-bit_Windows_Import_Library_Tool_for_C%2B%2B

In C++11 onward, a string literal (in your case, each string literal is a 'const wchar[N]' array) cannot be assigned to a pointer-to-non-const, as that promotes the ability to modify read-only data at runtime. In C, and prior to C++11, such an assignment was allowed. But BCC64 is a clang-based compiler that supports C++11, hence the warning (which is really an error nowadays). This is actually documented (albeit briefly) on Embarcadero's DocWiki: Common Warnings Porting from BCC32: Conversion from string literal to 'char *' is deprecated Stricter C++ Compilers: Type Conversions Yes, but don't do that. The correct solution is to make your array hold pointer-to-const elements instead (which you should have done from the very beginning), eg: const wchar_t *ConfigurationResultText[]={ // or wchar_t const * L"No error", L"CFGERROR: Unable to create file", L"CFGERROR: Unable to open file or file is busy", L"CFGERROR: Unable to perform file IO", L"CFGERROR: File is not a CFG file", }; Because it is required in C++11 onward. Assigning a string literal (which decays into a pointer-to-const) to a pointer-to-non-const was bad practice in earlier versions, so the C++ committee finally closed that hole. It is a 'const wchar[N]' array that decays into a 'const wchar_t*' pointer, not a 'wchar_t*' pointer. The classic compiler is not a clang-based compiler, and does not support C++11 (but has some C++11 features, but this isn't one of them). But adding the 'const' to the array element type will work in the classic compiler, too. If you run into a problem where you need to pass your string literal pointers to a legacy API that takes a pointer-to-non-const rather than a pointer-to-const, then you can type-cast (preferably using 'const_cast', not a C-style cast) at the call site, not in your array itself, eg: const wchar_t *ConfigurationResultText[]={ // or wchar_t const * L"No error", ... }; ... someLegacyFunction(const_cast<wchar_t*>(ConfigurationResultText[index]));

Only if you want to be able to use Indy components in a Form Designer at design-time. Otherwise, you can just create the components dynamically in code at runtime. Yes. Though, the runtime package binaries do need to be located where the IDE can find them when loading the design-time package binaries. Since you already compiled the binaries, you don't really need to compile them again, so you don't need to open the projects. The "Install Packages" dialog is just looking for the .BPL binaries. But yes, it would just be the two DCL packages. None. You already created them. Basically, you can't. But you can re-enable it when needed. No, you can't. But you can install packages on a per-project basis. So, make sure no project is loaded, and then go into the "Install Packages" dialog and remove the Indy packages. Then, load a project and re-add the appropriate Indy packages you want to use for that project. Then close the project, load another project, and repeat. As long as you maintain the separate Indy versions, you should be able to pick which version you want to use for each project. Of course, this is all just contingent on installing Indy in the IDE at all. If you create Indy components dynamically in code instead, then this matter becomes moot, since you can just make each project reference the appropriate Indy source/binaries folder as needed. Yes.

Don't forget to call JsonValue.Free() when you are done using JsonValue, or else it will be leaked. This is a common use-case for a try..finally block.

No, Community Edition does not include Konopka. The Feature Matrix even say so:

Design-time code (property editors, component editors, IDE wizards, etc) are simply not allowed in runtime executables, period. So, your home-grown component needs to be implemented in a runtime-only package, and any code that relies on the DesignIDE package needs to be implemented in a designtime-only package that "requires" the runtime-only package. Your component should have no concept of design-time whatsoever (outside of things like the csDesigning flag in its ComponentState property, the CM_DESIGNHITTEST message, etc). If that is not the case, then the component is not architectured properly.