Remy Lebeau

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.

Sounds about right. Modern Delphi prefers .dproj files for storing Project settings. When you open a .dpk file and no .dproj file exists, a new .dproj file is created from the settings in the .dpk file. And since you are not using a .groupproj file for a Project Group, a default Project Group is created for you, as well. Yes. And then repeat that for all 5 Indy packages (in this order): IndySystem, IndyCore, IndyProtocols, dclIndyCore, dclIndyProtocols. And then you can install the 2 dcl Packages in the IDE if you want to (replacing the old one), or just update individual projects to reference the newer non-dcl packages as needed. That, I can't answer for sure. It varies from one IDE version to another. I don't know what the default are for XE. You can go into the IDE settings to see exactly where the BDSCOMMONDIR environment variable maps to. That would probably be a good idea. If you go into the IDE's Packages list, you can see exact where it loads installed BPLs from.

There is no .BAT script for Delphi XE, only for C++Builder XE. Indy stopped using .BAT scripts for Delphi installations after D2009. Instead, you can simply open the 5 .DPK packages directly in the IDE (sadly, there is no Project Group file provided for XE) and then compile+install them from the Project Manager. You would have to maintain separate copies of Indy in different folders, and then configure individual projects to use one folder or the other when referencing the Indy packages/sources.

Is ICS using the SO_REUSEADDR/SO_REUSEPORT socket options? If not, then it should not be possible at all. It is possible to have multiple TCP sockets listening on the same port at the same time ONLY if they are listening on different IPs. Two sockets cannot listen on the same IP/port pair at the same time.

That is exactly what you would need to do. 10.1.1 is an EXTREMELY OLD version of Indy. The current version is 10.6.2. Be sure to read the install instructions first. Yes, you need those DLLs no matter what. But you would still need an up-to-date Indy to take advantage of those updated DLLs and configure them properly. It is very common for apps to use their own copies of OpenSSL DLLs, to avoid versioning conflicts, as the OpenSSL API tends to change from one major version to another. It should not, since that folder should not be on the system search path, but even if it were, the DLLs should normally be looked for in the app's folder first. But, Indy does have an IdOpenSSLSetLibPath() function in the IdSSLOpenSSLHeaders unit if you need to specify exactly which folder Indy looks in for the DLLs. The revision notes at the top of each Indy .pas file are EXTREMELY OLD, so just ignore them. They are a remnant from when Indy used TeamCoherence for its version control many years ago, before switching to SVN and now GitHub (neither of which store commit details directly in source files themselves). Then you have an EXTREMELY OLD version of Indy installed and need to upgrade. Not without upgrading, no. See my comment above.

Do NOT put non-system files in the System32 folder, they don't belong there. You can install your service from your own folder just fine. On a 64bit Windows, the System32 folder is for 64bit files only. 32bit files would have to go in the SyWOW64 folder instead. But again, don't put your service app in either folder to begin with.

LibreSSL is backwards compatible with OpenSSL 1.0.1, so Indy's OpenSSL loading code has *very limited* support for detecting LibreSSL at runtime and not failing on it. But that is no guarantee that it will actually work correctly for all operations, so use at your own risk. Otherwise, you should install the actual OpenSSL dylibs directly in your app folder instead.