DelphiUdIT

This is the direct link: https://ats.rippling.com/partnerco/jobs/79f36155-18a0-465f-a787-8f2448a55e09 EDIT

I don't have any IDE experts installed (except BCompare), no Parnassus, no getit package except D4P, JCL, JVCL and Indy compiled from github. I removed FIREUILivePreview and EMS components (not compatibles with Indy from github). Except for what I have signaled on QP (AV when switch from Delphi to Mixed Delphi / C++ prj and a Issue with project panel view). I don't have other problems. I used Rad Studio, and switch without close it from Win64 Delphi project and Android Delphi project with debugging either. Changed also the SDK settings (for various release of Android). Always without close the IDE. No issue at all. Like others I'm lucky.

First of all you should know why the file is not deleted. AFter that there are other ways to delete a file, for example when is locked. BUt this go over my competence.

If there are DLL required for python here is the logic, from: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order LOL: I really didn't know about that "The 16-bit system folder. There's no function that obtains the path of this folder, but it is searched."

The midas.a that you have create is a symbolic link (or better a container of symbolik links...) for a MIDAS.DLL and you must deploy MIDAS.DLL with your application. You cannot create a midas.o (or static library) without the source. No chance.

I think should be better that you create the Python engine in a START event of controller, and Free it on Destroy event. Execute method is call more times during the "live" state of Service. Bye

"TokenUser" is a an enum member of TTokenInformationClass defined in WinApi.Windows. You have redefined it in you local variables. EDIT: of course you can use TTokenInformationClass.TokenUser instaed ...

I suggested the same in my previous post

There are lot of packages for Delphi and C++, look at GETIT from IDE and search for: 1) asyncpro or 2) serial I have been using this component for a long time too: https://sourceforge.net/projects/comport/files/comport/4.11/comport411f.zip/download To read the Help you must use an old WinHelp executable. You can discharge it from Microsoft (I had ones for Windows 7 and is working in Win 11). Bye

I don't expect that they change anything and I express explicity that. But I think that signal it is a chance to go better in the future.

Sorry, i mention 16 bit register only for quickly "writing". Of course the implementatio was on 64 bit register. Of the cases you indicated, I have honestly never noticed them (I don't go to debug in assembler unless there is a specific reason). I don't work much with strings, if not merely for the visualizations on the UI and therefore I have not noticed problems such as performance drops or anything else. I sometimes look into assembler, I produce exclusive 64 bit application and no more 32 bit, and I saw that they use tipically REX (so pure 64 bit instruction) and rarely 32 bits instructions (with 32 bit arguments), it may also be that the latter are reminiscences of the past. Of course, for a perfect code as you indicated (and as I would also like it to be) there would be a lot of indications to follow ... in reality I think that the projects (like the compilers) have been carried forward by adding functionality without ever rewriting them from scratch and therefore they necessarily carry with them some legacies of the past. Putting in place all those precautions with which the code could improve both its functionality and stability and perhaps even security is an effort and requires a lot of resources.

I write "really weird" because if you use manually "mov ax, source" and "mov dest, ax" you do it more quickly, and not a little bit. "movsd" and his brothers are complex instructions (like you link): https://uops.info/html-instr/MOVSQ.html The use of them should be carefully considered and evaluated. In the Intel Reference Manual (Intel® 64 and IA-32 Architectures Software Developer’s Manual, - Ed. JUNE 2024) they told about these instructions: So, they should use in these cases (I don't look more deep) to be "fast", otherwise they are "poor" (may think). I don't know if Embarcadero can think (and of course want) and resolve this situation, whether there really is a need to fix it. We try near a bilion of cycles, but it's really a normal situation ? P.S.: I try the same in Lazarus / FPC and the timing is lower (near 400 ms.) for double operations in x64 and their compiler use normal "mov [RBP...], RAX" and company to execute the same work.

I have open an issue to QP: RSS-2192

x64: It's incredible, but writing 3 times in memory is more fast that using MOVSQ ... really weird hardware implementation, may be that this works better with long data, like string. The x32 implements in facts 3 single writing (if datatype is "single") and with "double datatype" use the similar weird approach like x64 with more high timing because it's 2xMOVSD in use.

This should be another way to do (like @Kas Ob. suggested): //l_vec3 := k_vect3_nul; //option 3 for var i := Low(l_vec3) to High(l_vec3) do l_vec3[i] := k_vect3_nul[i]; //option 3 It's more fast then the orginal in x64 and near the same more slow in x32

It should also be kept in mind that the number of cycles (almost a billion) has a significant impact on the times: even in modern processors, using a "machine" instruction that takes 1 cycle more than another corresponds more or less to having an equivalent time of about 400 ms more (taking into account a base frequency of 2.5 GHz of the single Core and only the theoretical calculated time).

Like me and @Kas Ob. said something wrong with the assembler coding. In theory the compiler do the right way (my personal opinion), but the timing is not right ... should do more study about that. Now I look to my code also, I facing some problems that may be originate from that. I don't think tha Embarcadero do something in real time ... surely they will improve in the future. You can open a bug report on new quality portal.

The difference depends from assembler decoding: for example if use the "option2" and all single (x32 and x64), the x64 is more fast .... May be can be optimize better, but on compiler time. If you want you can write an assembler function that do something better. EDIT: seems that an indirection write use [si] and [di] cpu registers is really more slow that other tecnique, that is know but I really don't think that is so slow...

Replace: //l_vec3 := k_vect3_nul; //option 3 move(k_vect3_nul, l_vec3, sizeof(t_vect3)); //< Edit with sizof(type)

Ehmmm, I explain bad, it's your update. The Palette come from Indy source repo, already in the recenct past he was added (form Oauth-ssl branch ?). All other points, I already know about them of course and I tried in the recent past the very first commit of TLS-OpenSSL with success. But I wanted to try the PR299 for historical test and to see if LivePreview was working like in the past (In the 11.x, 12, and 12.1 LivePreview was working with Indy Repo applied).

I install the new Indy from github and the old PR299 (with the same changes like always to maintain compatibility with Embarcadero environment and third parties) and all is working with RAD 12.2 Patch 1. I tried with the SSL DLL 3.1.5 for HTTPS and e-mail (not Oauth) and is working. Also the new OAuths in the components palette. I didn't try them. The new (but it worse) is that "LivePreview" should not be installed. It generate AV in the IDE on startup and shutdown.

I always do a clean install. I never used migration tools 'cause heavy issues in the far past. FIrst thing is backup the "Styles" and "Style Template" folders. Uninstall every getit packages (really fews). After I have disinstalled RAD STUDIO, I do those steps: 1) Delete the Windows registry (and all subfolders of course): HKEY_CURRENT_USER\Software\Embarcadero HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Embarcadero 2) Delete the folders (and subfolders) of my disk (YOURACCOUNTNAME is the name of my account): C:\Program Files (x86)\Embarcadero C:\Users\YOURACCOUNTNAME\AppData\LocalEmbarcadero C:\Users\YOURACCOUNTNAME\AppData\Roaming\Embarcadero C:\Users\Public\Documents\Embarcadero\Studio\23.0\Bpl C:\Users\Public\Documents\Embarcadero\Studio\23.0\Dcp I left this path without delete anything, 'cause normally have no relevants for issues (only one time this locked an installation, I had to delete it to continue). C:\ProgramData\Embarcadero

There is also another resource on GitHub (in some topics of this forum there are some references about that): https://github.com/geoffsmith82/GmailAuthSMTP

With Indy is a little bit complex, you must install the github version and a branch "ssl-oauth". You must delete the original Indy shipped. But now some works were done and I don't know how is the status of Indy repository and relative branch. Alternative the is a thirdy tool not free (based on Indy): https://www.esegece.com/ You can try also ICS that is free, but I don't know if they have implemented Oauth protocol: https://wiki.overbyte.eu/wiki/index.php/ICS_Download Bye

If you have thirdy parts component installed try to delete them. If this don't help, you can try to do a clean install. After you have disinstalled RAD STUDIO !!!, do those steps: 1) Delete the Windows registry (and all subfolders of course): HKEY_CURRENT_USER\Software\Embarcadero HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Embarcadero 2) Delete the folders (and subfolders) of your disk (YOURACCOUNTNAME is the name of your account): C:\Program Files (x86)\Embarcadero C:\Users\YOURACCOUNTNAME\AppData\LocalEmbarcadero C:\Users\YOURACCOUNTNAME\AppData\Roaming\Embarcadero C:\Users\Public\Documents\Embarcadero\Studio\23.0\Bpl C:\Users\Public\Documents\Embarcadero\Studio\23.0\Dcp C:\ProgramData\Embarcadero Take care about you are doing.