DelphiUdIT

All the CCR realted files should be in the project directory, or you must add the path lib where these files are located (in the project options or in the tool/language/ Delphi options). If the CCR is a standalone project group (runtime o designtime) you must build it after the changes (and the path that you should use is the path where the CCR project group save the DCU files). If the CCR is only a set of Pascal source, your path lib must be the path where the sources are located. Bye

I have no notice about that. ".Net" have the same problems like all other development tool, they update their tools also for resolve bugs. But many times is the human works that induce the problems, not the language or the development tool.

The memory of your program is private and not others applications can normally access it (some Microsoft tools will be able to do this, like some antivirus). So if the memory were corrupt over the time normally it is the application itself that is the cause of it. Take care that your application use all kind of Microsoft (like in all other OS) services, DLL and driver. May be that those are some bugs (need to maintain update the environment like OS, drivers ...). P.S: but if you go to Windows event log like I told you can see something.

I did something similar many years ago, then I abandoned this path because all the problems were solved and there was no longer any need for a similar approach. What I did was use a program external to the application (not a service) using it as a "dumb" TCP server to collect information from all the other applications and their threads. The reception had to have updated data (for example the number of cycles performed, the status of the connections, the number of polling performed on all devices) and through a rough analysis performed by this external application on which the TCP server ran, any alerts were displayed. At the time I also took into account the revolutions that an encoder performed (an encoder is a device that counts the rotations of a mechanical shaft) to match it with the cycles performed and if they did not match then alarms were sent from all sides (it cannot be said, but the application sent the data privately via its own internal mail client connected to my company server so that we had everything under control, similar to "analitycs").

Like all electronic devices, memory, processor, motherboard, SSD and everything else can fail, generating the most varied errors. Generally, the failures essentially depend on either electrical failures caused by overvoltage or similar situations or failures related to overheating (for example in the case of overclocking and inadequate ventilation). Obviously we are talking about normal Home PCs, because if we are talking about systems (for example industrial or commercial) then the case history is much more extensive. If you have a latest generation Intel processor (13th or 14th) and above all if you have tried to overclock it, it is possible that the processor is failing (see Intel's note ... now they have solved the problem but this anomaly has lasted until now ... the link is no longer active). AV can also be generated by failures of the SSD that reports incorrect data to the application. However, if you go to the Windows event log you can take a look ... normally the anomalies are reported there ...

Tihs article explains something .... the $1332 value was a predefined default value on some old Delphi editions .... may be before Delphi 12 in wich they change the standard mask of FPU exception. I don't know if this is a casuality about the standard VB setting needed to work, but ... EDIT: https://stackoverflow.com/questions/39684161/why-an-application-starts-with-fpu-control-word-different-than-default8087cw

I used in the far past this setting (only one time, at the begin of Delphi program, or better in the thread where the ActiveX is instantiated) before calling any MS ActiveX: Set8087CW($27f); Hope this help.

Normally I always use SQLite as a base for all my applications (configurations, settings and more are kept inside). Then depending on the customer, additional databases such as MSSql, MySql, Firebird are used in addition, but with the server managed by the customer. However, the use of databases in addition to SQLite is sporadic, many customers want to have the data in an open format of pure text such as a CSV file.

The first Item of a list (ITEMS -> ItemIndex) is ZERO not ONE. ComboEdit1.Items.Clear; ComboEdit1.Items.Add('A'); ComboEdit1.ItemIndex := 0; <---------- SHOULD BE 0

It could be that they simply do not want to make future choices public because they have not planned them as resources yet. For example, rebuilding a 64-bit IDE is expensive, as is porting it to ARM. These are just hypothetical examples and have no connection with Embarcadero. There are no mysteries, we just have to wait for them to publicly inform us about future plans. Bye

You are right, my brain went on Holiday ... 😞

If you want, you can try this. Is the same COM but with new application: you don't need to register the COM Try to unregsiter the old one. After that build the projetc group (it is setting for WIn64 but you can change for WIn32) and run ... all is working without register the COM thanks to SxS technology (SideBySide). The EXE and DLL will be put in Bin32 and Bin64 (and there are already the manifests). There is a ReadMe and some Manifests (they are all equal excpet for the manifest that is included in the Project1 options). Bye Demo COM SxS.zip

Uhmm... I don't know for the past, but in Delphi12 NaN is defined like 0.0 / 0.0 (yes zero divide 0), so don't try to use it with unmasked exception ...

No it isn't. Change the IDE means change the World (all components whould be at 64 bit for example ...). In the last webinar they told they are working about but it's not time to have a date to release. Bye

Another thing about COM objects ... look at thread mission (ciMultiIstance, tmApartment) and how they work. Also be very carefull to use global variable for working COM. I suggest you don't use anyglobal variable (except const).

If you want this is the global project (DLL_COM + APP) with WIDESTRING result use .... It's only a basic skeleton of course. Bye Demo COM.zip

May be with the use of property, (remeber something with my very old use of COM) I can exchange widestring. I remeber to never expose directly string as return function. Let I try to modify your COM ...

May be you're right, the return function as string should be a safearray. Instead to use return value, use that as parameter: procedure TMyCOM.DoIt(Value: WideString); stdcall; begin Value := SValue; end;

How is your RIDL definition of COM class ... may be there is the issue ...

To summarize: x86 (32-bit): 1) "Quiet NAN" can always be used; 2) UnMasked Invalid Operation : - "Signaling NAN" throws an exception if used with FPU registers (i.e function return value); 3) Masked Invalid Operation: - "Signaling NAN" is switched to "Quiet NAN" if used with FPU registers (i.e function return value); N.B.: if you pass the "Signaling NAN" via function parameter then you can use it 'cause no FPU register is involving. x64 (64-bit): 1) "Quiet NAN" can always be used; 2) "Signaling NAN" can always be used;

The result value is coming from FPU register ST(0) like @David Heffernan told. The issue is that the code load in ST(0) the correct signaling NAN, but become quieted NAN in ST(0). This is not an Issue from Embarcadero, but may be an hardware setting. I am far from FPU registers (working with them at time of I486DX ). EDIT: From what I read in the Intel manuals, it seems that the impersonation is internally QNAN if the FPU "invalid operation" exception is masked. (ref 4.8.3.6 of Intel manual "325462-sdm-vol-1-2abcd-3abcd-4"). There are many tables inside that show how hardware treats the NAN.

The Indy "Crew" sayd that this change will be done in the next version (Indy 11). By now you can only change (may be MUST) that at your hand. This is necessary if you want maintain compatibility with Embarcadero tools and also some thirdy party components that use Indy. But Embarcadero is interested in Indy's progression, so things will be fine (https://www.indyproject.org/2024/08/05/ongoing-work-in-indy-for-openssl-updates/)

The "sasl-oauth" branch will also be useful to enable the use of the OAUTH protocol, especially for email client functions.

Uhmm ... during my tests maximum charge of CPU is 4% ... I don't think that any other normal load can change the timing in impressive way. Of course depends where you need these works. In my applications I will not able to use parallel algo, like already discuss in other posts cause heavy load (85% of CPU). but I never used in my life any sort algo, 'cause normally I had only maximum of some hundred of elements and I use normal shitfing (memcopy) in entrance of array. Bye