DelphiUdIT

I use them (almost more then 10 years) and I never had any issue with. And in every project there are one or more component of Jedi (visual and not visual). I always use the github version https://github.com/project-jedi

Take from "System.Curl"

There is an help in Rad Studio, It's old but some it is still valid.

But you don't need it, it was only a demonstration, I think from your last post that you are already resolved. Bye

I attached a zip file in the previous post : https://en.delphipraxis.net/applications/core/interface/file/attachment.php?id=11265 Inside there is all, two Delphi projects and a Python script.

Let's explain ... I'm not an expert about Python, but i work on some P4D projects and I see some issues (they are not really issues, but you cannot do some things if those happens). Look for script TEST.PY and Delphi lib pyTRYSF.pyd in the attached example. First of all: instead to do "onefile", do the standard distribution that pyinstaller do ... try only (from the pyinstaller environment): pyinstaller test.py This will create the folders that containing the executable and all the necessary files (including your .pyd library compiled with Delphi): dist\test\_internal Inside "dist\test" ther will be an executable (test.exe) and in the subfolder "_internal" should be all necessary for running the exe, INCLUDED pyTRYSF.pyd) !!!! For running any delphi library with Python is necessary to link the Pythonxxx.dll main engine at runtime. This mean that this engine should be found. When you run a python script that import a Delphi dll normally (eg. after you installed Python in Windows) your module can link the standard pythonxxx.dll library installed and is the same that the python "shell" call. If you are running the test.exe program created by pyinstaller, the pythonxxx.dll library is not the standard library, but is the DLL that is inside the "_internal" subfolder, where the pyd module is too. This "_internal\pythonxxx.dll" should be link at runtime by Delphi dll (pyTRYSF.pyd in the example). If you don't link this at runtime, you will never be able to execute your "pyd". In the example attached there is an example how I modified the link engine procedure to search the correct lib ... it works without changes with installed python engine or with pyinstaller (but no with --onefile parameters). Why the --onefiles parameters doesn't works ? 2 are the issues: 1) The pyd is not included by pyinstaller in the executable (with --onefile). 2) The executable unzip the same files like "_internal" in a temporary directory. This lead the impossibility to link the pythonxxx.dll because when the test.exe is executed the execution path is the ".\" of the test.exe an not the temporary directory. There are no chance for Delphi pyd module to link the correct pythonxxx.dll. May be the P4D guru can help in this. Bye N.B.: the example works only with Python 3.12 by now. DelphiDLLforPython.zip

I have a lot of components installed and had no issue (except for know incompatibility beetwen "new Indy from repo" and "Embarcadero RAD Server Edge Components"). I don't usually use plugins, and I found the same like others told, Parnassus Debugger plugin emit every time some AV, either in debugger sessions (not often) or when closing Rad Studio with open project ( issue from old portal is RSP-43335, issue from new portal RSS-1243). I simply use TaskManager ('analyzes waiting chain' or similar) and Process Explorer to find the module (apparently responsible).

It seems that, according to the limited documentation, they never left the "alpha" phase (year 2005).

To view COM components from IDE, your assembly should be compiled for 32 BIT explicitly (so you must have two dll register, 1 for 32 bit and one for 64 bit if you produce 64 exe). Other way is to import it using the bin64\tlibimp,exe or /bin/tlibimp.exe utility (produce the _tlb pas file). If you have only the 64 bit dll, you can use it at runtime. Example: "C:\Program Files (x86)\Embarcadero\Studio\23.0\bin64\tlibimp.exe" -Ha+ -Hs+ -Hr+ -Ya- -O+ -R+ -W+ -Wc+ -P+ "C:\Windows\System32\Speech\Common\sapi.dll" Import SAPI COM from Windows system and generate _TLB PAS file (also call wrapper).

To @Remy Lebeau if you want add this library (OpenSSL Android 1.1.1n) to experimental binary directory on Indy repo. https://cloud.dyn-o-saur.com/Android lib 1.1.1n.zip I try this version on Android 11 phone (Arm 64 bit), of course with Indy and new SSL IO Handler (PR299 archive). Bye

He said to use 1.0.2s version. This means that the library should be that version. I only suggest to load on the default library path and see what happens. In the past time I have some issues with some versions of Android with .so libs loaded around the systems (in Shared Doc, External Doc, etc...). So I always loaded them in the default library paths.

I'm using to deploy the .so files in "library\lib\arm64-v8a\" and I don't have to do nothing at startup, no loads or other ... Try to put only: ShowMessage(OpenSSLVersion()); in a Form Create event and see if the version will show.

This may help: https://learn.microsoft.com/en-us/windows/package-manager/winget/upgrade

To include Socket components, you must add component through menu "Component/Install Packages" and search at bin directory (like in the images). The socket package is deprecated, but it is still present.