Remy Lebeau

Why are you putting your Java class in an Embarcadero package? You should be creating your own package. How does your C++ project refer to your MySimpleClass.jar file? Did you use the Project Manager, or a manual classes.dex file? Have you considered creating a JNI Bridge to your class, instead of manually using JNI methods directly? Using a Custom Set of Java Libraries In Your RAD Studio Android Apps Creating and Deploying a classes.dex File Manually Adding A Java Library to Your Application Using the Project Manager Something else to keep in mind (not sure if this applies here): https://stackoverflow.com/a/20843365/65863

Can you be more specific? What exactly was disrupted? It makes sense that lack of OpenSSL DLLs would cause errors for clients that try to connect using TLS, but that is handled on a per-client basis, it should have disrupted the entire server as a whole. Once a TLS handshake begins, if TLS fails for any reason, you can't continue communicating with that failed client, the connection must be dropped. OpenSSL MIGHT be able to send an alert to the client, depending on what stage of TLS the error occurs at, but that is the extent that can be sent. You certainly cannot send the original exception back to the client. On the other hand, if an exception happens that is not related to TLS, then you can certainly catch it and send whatever you want back to the client, but that depends on the design of your application protocol. As long as you do that in a thread-safe manner, it shouldn't affect other clients.

Does that mean you are using the "current" Indy version that shipped with 11.3, or you are using the "current" version from Indy's GitHub? 11.3 was released 2 years ago.

Are you sure that is the real error? ParseJSONValue() does indeed have an overload which takes in a string. However, the TRESTRequestParameter.Value property is also a string, but ParseJSONValue() returns a TJSONValue object pointer. So you would need to either just get rid of the TJSONObject entirely: var aParam: TRESTRequestParameter; begin aParam := RestReq.Params.AddItem(); //don't care about setting a name for it aParam.Value := '{"payment_method":["credit-card","open-banking"]}'; ...... RestClient.Execute(); end; Or, convert it to a string: var aParam: TRESTRequestParameter; aObj: TJSONObject; begin aObj := TJSONObject.ParseJSONObject('{"payment_method":["credit-card","open-banking"]}') as TJSONObject; try aParam := RestReq.Params.AddItem(); //don't care about setting a name for it aParam.Value := aObj.ToJson; finally aObj.Free; end; ...... RestClient.Execute(); end;

Just because modern OpenSSL is not directly in Indy itself yet does not mean there are no options for it at all. For example: https://github.com/JPeterMugaas/TaurusTLS Did you see this? https://www.indyproject.org/2024/10/20/sasl-oauth-support-finally-added-to-master/

Yup, that's the boat I'm in now...

HA! Yeah, like that'll never happen (famous last words!). My current company uses Java/Typescript, C#, and Visual C++. They had like 1 Delphi side project many years ago, but it hasn't been touched since and I think it got replaced with something else. My previous company, on the other hand, used C++Builder pretty extensively, and my boss at the time was well-aware of my TeamB activities.

And that is.... what, exactly? It is not a good idea to just post a link to some random code and expect people to understand what you are doing.

The CustomHeaders property is an indexed property. It is used only to read/write individual headers by name. You are seeing the methods of a single UnicodeString instance. There is no option to clear the whole list using the CustomHeaders property. However, you can use the CustHeaders property instead (not to be confused with the CustomHeaaders property!). It gives you access to the whole list, and it has a Clear() method: nhc->CustHeaders->Clear(); // NOT nhc->CustomHeaders->Clear(), // which does not exist....

At work, certainly. But if you mean my involvement in the Embarcadero community, then no. I keep those two worlds separate.

Agreed. My boss can't stop raving about it. AI this. AI that. Everyone needs to use AI. The last few weekly 1x1s I've had, lets check your AI usage this week. It's getting rediculous.

Do you mean SafeLoadLibrary()?

LoadLibrary() is a Win32 API function, so it is only available on Windows, you CAN'T use it on other platforms. That being said, other platforms have their own equivalents. For example, 'Nix-based platforms (which includes OSX, iOS, Linux, and Android) have dlopen() instead. You are going to have to use the appropriate API for each platform you want to support.

And if you run into problems with that, see:

Command line redirection is performed by the command line interpreter Try adding the /C parameter when invoking cmd.exe directly: DeviceIdCmd := '/C ' + AnsiQuotedStr(ExePath + '\idevice_id.exe', '"') + ' > ' + AnsiQuotedStr(LogPath + '\idevice_id.log', '"'); ShellExecute(0, nil, 'cmd.exe', PChar(DeviceIdCmd), nil, SW_HIDE); Alternatively, use CreateProcess() to execute idevice_id.exe directly and capture it's output to write to the log file yourself: Creating a Child Process with Redirected Input and Output

Is there a firewall, load balancer, or other similar system running in front of the server? Typically, the only reason for a "connection refused" error is either: - the connection is trying to access a port that is not open. - the connection reaches the port but the backlog is full. - the connection is rejected by a WSAAccept() callback. - a firewall or other system in front of the server is blocking the connection.

Sorry, I'm a little late to seeing this... I see it the other way - it can INCREASE the likelihood of an AV (or worse!). The callback's Self pointer will be pointing at memory which the now-dead TMyClass object was occupying. It's undefined behavior for the callback to access that memory for ANY reason, period. But let's forget that for a moment. You nil the FMyVar member when freeing the TMyClass object, with the expectation that you can still access FMyVar later (which you can't). If the memory that FMyVar was occupying gets reused and overwritten before the callback is invoked, that memory might not be zeroed out anymore from the earlier nil. And if it is not, then Assigned(FMyVar) will return True instead of False (if it doesn't just crash outright), and then you will try to call FMyVar.Add(...) and crash... or worse corrupt random memory trying to write to memory that it doesn't own.

AFAIK, that PR works, but is effectively dead as Mezen is no longer working on it. The current efforts that are actively worked on at the moment are: https://github.com/MWASoftware/Indy.proposedUpdate https://github.com/JPeterMugaas/TaurusTLS At some point, I will get this repo released and then updated with whatever new code will work going forward: https://github.com/IndySockets/IndyTLS-OpenSSL

This doesn't guard against anything. if DoOnCallback() is called after the TMyClass object has been freed then all bets are off. The callback's Self pointer will still be pointing at the memory of the freed object, but that memory MAY OR MAY NOT have been overwritten by the time the callback is executed. You are assuming it has NOT been overwritten yet, but you can't make that assumption. You really should cancel the async operation before/when freeing the TMyClass object, so the callback is not called at all. But, if that is not an option, then a safer option is to keep track of the dead object pointer somewhere and have the callback check if its Self pointer is being tracked as dead before accessing any members.

Equivalent, but not identical. Do keep in mind that there is one slight difference - FreeAndNil() nils the pointer before destroying the object. It is basically doing this: var tmp := FMyObject; FMyObject := nil; tmp.Free; So, if the call to Free() happened to raise an exception (ie, due to memory issues, or a bad pointer, etc), then the difference is whether FMyObject gets nilled or not. But in normal well-behaving code, this difference is negligible.

You will have to call Get8087CW() first and save the value before calling Set8087CW(), then do your work, and then call Set8087CW() again with the value you saved. Do this in each of your exported functions that suffer from the problem.

The only way to make your ObjectIdentifier be a unique type in C++ is to declare it as a class or struct, either with an AnsiString data member, or maybe even derived from AnsiString. You could declare ObjectIdentifier as {$NODEFINE} on the Delphi side. But, you may or may not run into compatibility issues, so you should consider making ObjectIdentifier be a record on the Delphi side and then the compiler can general a compatible struct on the C++ side.

If you want to quote multiple messages at one time, you can click on the '+' button on the bottom of each message, and then click the resulting "Quote # posts" popup when ready. If you want to quote multiple sections of a single message, that takes a little more work. In an original message, you can highlight the text you want to quote, then roll the mouse over the selection and click on the resulting "Quote selection" popup. Repeat as needed. Alternatively (on a desktop browser only, don't try this on a mobile browser, it doesn't work well)... after quoting a message, if you put the edit caret inside of the quote text where desired and then insert a few line breaks, SOMETIMES that will automatically split the quote into 2 separate quotes, and then you can add your responses in between them. But, that split does not always work, in which case I end up having to copy/paste/edit the quotes to get what I want. Roll the mouse over a quote and you will see a little box appear in the top-left corner of the quote. Left-click on that box to select the quote as an object, then you can copy/paste the quote, and then edit the quotes as needed. You can also drag&drop quotes using that little corner box, too. Quoting can be a headache, err, art form on this forum! Yes. How would I do that? Adjust these: Default8087CW, DefaultMXCSR, DefaultFPSCR, and DefaultFPSCR Somehow in the older compiler version? Have you read the documentation yet? https://docwiki.embarcadero.com/Libraries/en/System.Default8087CW https://docwiki.embarcadero.com/Libraries/en/System.DefaultMXCSR https://docwiki.embarcadero.com/RADStudio/en/Floating_Point_Operation_Exception_Masks

Hard to say. I find it very unlikely that file I/O would report that particular error. It would be helpful to see your actual file I/O and error handling code. I wonder if something is sitting in between your file I/O and error handling that might be affecting the error code unexpectedly. When retrieving the OS error code, you need to retrieve it as close to the failed API call as possible, you can't make any other system calls first. All the more reason why I don't like using IOUtils with all the extra overhead it has, particularly any memory cleanup.

I've written a fair share of DLLs in BCB6 that work just fine in other compilers, including MSVC. Never had a problem with that. Makes me think that either you are doing something weird/incompatible that you are not showing, or maybe you are linking in another library into your DLL and that library is incompatible in some way. Hard to say without a reproducible test case. You can call the Form's Update() method to force an immediate repaint. That implies your EXE is calling the DLL functions in a loop that is not processing your UI's message queues in between calls into the DLL. That is not a good design choice, especially for a DLL with a UI. I would suggest either: moving your DLL's UI into a worker thread with its own message loop. having the DLL export a function that the EXE can call periodically to pump your UI's message queue. If the EXE has its own UI, then simply break up the EXE's logic to work asynchronously so its own message loop can also service your DLL's UI. Have you considered using the Remote Debugger? Now we're getting somewhere useful. RAD Studio 12.0 did make changes to how it handles floating-point exceptions: https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Disabling_Floating-Point_Exceptions_on_All_Platforms On older versions, sometimes you do need to adjust the exception masks manually. Particularly for MSVC compatibility.