DelphiUdIT

I, and not only me, have noticed that the instability of the IDE is mainly due to (in my case ONLY to) third-party components installed in the IDE. For a long time now I have been trying to use third-party components (there are few that I install now) only at runtime. And where a graphical surface defined in the FORM is needed, I "hook" them to invisible TPanels placed at design time. Of course, not always it's possible but when it is that save me about those issues probably.

The "Adopt" is there, empty from the previous version ... I don't use Adopt, I use Oracle JDK 22. Of course, I agree ... and may be that if someone knows the answer ... is under NDA. But I've never seen different versions of the NDK than the IDE build. I probably never paid attention to that.

Are you sure ?

If you have installed Android, also AdoptOpenJDK should be installed (it is the default Java SDK that Embarcadero install). Search for that in "Program FIles" or "Program FIles (x86)" .... If you have installed any other Java SDK it's OK from version 17. I have Java SDK (version 22) from Oracle. In the SDK Manager, you must choice the correct Java.exe from the Java SDK installation bin.

Put those two define lines in a DPR file of your application after "program" section in 10.4 and buld it with x64: program ..............; {$SETPEOPTFLAGS $40} //SET ALSR ON (Address space layout randomization {$SETPEOPTFLAGS $020} //SET HEVA ON (HIGH ENTROPY VA) You will see (should) the same issue.

The changes that were done are the enable of ASLR and High LOAD in all projects (old and news). WIthout this the component works, OR BETTER SEEM TO WORKS. Don't put you hand over the fire about this. Like I told the component is derived from very old projects, and it's near the true that is not "fully" compatible with x64 tech. The full project should be take in care and updated to x64, looking everywhere in the code. EDIT: to better explain, in the x32 the pointers are 4 bytes long, where in x64 are 8 bytes. If you don't use the "high memory" is possible that all works ... but really always ? Look there: https://docwiki.embarcadero.com/RADStudio/Athens/en/Converting_32-bit_Delphi_Applications_to_64-bit_Windows

UPDATE: IT WORKS DOING SO: But this is only an "escamotage" because this means that in your components there are something not working with WIN64 convention ... normally are the pointers ...

EDIT: READ NEXT POST I try to debug it, but something goes wrong in the source (compiled system unit) of IDE. There is no chance (or better I was not able) to let it works or diagnose what is the problem. The only thing that I catch is that is generated an error (0xc000041d), in Microsoft that means: Link in Italian: https://support.microsoft.com/it-it/topic/errore-ntstatus-0xc000041d-si-verifica-quando-si-fa-clic-su-un-collegamento-in-un-applicazione-basata-sul-web-in-internet-explorer-10-in-windows-8-o-windows-server-2012-49b8cfdd-a841-06ce-ae60-8c04ff74a2f3 If you use the IDE standard component TWebBrowser all works.

This is a works derived from old github repository. Most of the definitions are included in new IDE (like SHDocVw of IDE that have more complete defines). For example, this is something differents: Embedded define from SHDocVw_EWB (look var PostData): IDE define from SHDocVw (look const PostData): Since those project come from very old one, I think it's really difficult to define what is the issue: the lack of source code for your app, related to how you use the component, then does not help.

I made some times ago this to retrive the p-core (I think is similar to that used in the post from @Anders Melander ) : use Windows.System.SystemInformation; //this come from WINMD (getit) //Result = 0 --> No Hybrid system //Result = -1 --> DIFFERENT RECORD LENGTH (API VERSION OLD OR NEW) //Result = -2 --> API Error //Result > 0 --> mask with Power Core (no more than 63 core, or the result type should be change) //Tested only with Intel x64 CPU (no Xeon, no Numa system) function GetCPUPowerArray: INT64; var CPUInfoSet: TArray<SYSTEM_CPU_SET_INFORMATION>; dwlengthsize: ULong; begin Result := 0; dwlengthsize := 0; setlength(CPUInfoSet, 0); GetSystemCpuSetInformation(nil, 0, dwlengthsize, 0, nil); if (dwlengthsize <= 0) then begin Result := -2; exit; end; if ((dwlengthsize mod sizeof(SYSTEM_CPU_SET_INFORMATION)) <> 0) then begin Result := -1; exit; end; setlength(CPUInfoSet, dwlengthsize div sizeof(SYSTEM_CPU_SET_INFORMATION)); GetSystemCpuSetInformation(@CPUInfoSet[0], dwlengthsize, dwlengthsize, 0, nil); for var i := Low(CpuInfoSet) to High(CpuInfoSet) do if (CpuInfoSet[i].CpuSet.EfficiencyClass > 0) and (i < (sizeof(INT64)*8 -1)) then begin Result := Result or (1 shl i); end; setlength(CPUInfoSet, 0); end;

I don't know the EmbeddedWB, so I cannot help you. Sorry.

Read here: https://docwiki.embarcadero.com/RADStudio/Athens/en/Floating_Point_Operation_Exception_Masks The math exceptions are already masked from AThens 12. P.S.: @Brian Evans sorry, I write concurrently with you.

I think you are in the right way. Think about HTTPS transfer and may be a simple login (sending username and password for example).

There are too few informations to do a proposal: - they should work inside a LAN, a WLAN, Internet ? - they should work inside an office, a complex structure ? - how many processes will there be? 100 per seconds, 100 per hours ? -etc ...

I know that EVERY components of FMX project should have 'Name' property SET. And of course all must be differents.

Take care about that the Form, I dont'know if is with new version of IDE, have the "ParentFont" set to FALSE ... In this case the "Application.Default....' is not working 😞 The images come from an old base project that I use for quick test and I see that "ParentFont" value is in BOLD, meaning that is not the default. Create new App, the Form has this property set to false ....

Of ourse the font should exists ... This is the default font setting. This is the modified setting from DPR, without changing nothing in the source or design.

If you post here the piece of source code interested and the screen shoot, sure someone can help you.

Good question. I don't know if is possible ... the defaults should be written by desgin packages ... , but the first thing that I think is to change the default font of TApplication at the start of program , so at runtime time every components that have the "ParentFont" property at true still had that font. But this is only a temporary adaption: when you'll edit the form, I think the all components will change cause new default font. May be some regsiter hack from a dummy design package can help .... (like Register(TForm, MyNewDefaultForm)) ... but I don't know if it's possible and how to do that.

You can run with debugger and see what's the cause ...

I used to loose Form states (or better don't care about them anymore) every time it is closed or hidden. These because all the states of the Form (like input datas, charts, state of the controls) will be resumed from a structure (typ. record or advanced record) when the Form is "reshow". Normally I "deep divide" all data values from graphic controls and save them to records, since these values may be (normally ARE) used and modified by other means. Only when I have DBAware controls I normally maintain the state of the Form (never destroy it or resume data when the Show methods are called).

Insert in every child forms this line in the OnCLose Event may be resolve the Issue ? procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction); begin Action := TCloseAction.caHide; end;

I partially agree with you: measuring (always my experience on software and system that I have done, and view competitors's solutions) the performance (timing based) seems that HT in my case is better. I used with the same twins systems HT and not HT (with Alder Lake) and with HT I gain form 15% to 20% of better performance (timing lowered from 150 ms. to 120 ms. with HT). Of course it is my case, and my be should be better "thinks" for not HT. Ahhh .... the tempearture were lowered from 85/90 C to 80/85 C. There is a scope about that ... an application (or better a system) should (MUST) achieve the "GOAL" ... the price and the techs. go in second plane (of course ALL should be OK, techs, economy, profit, ect ...). Like I told there is no notation about that CORES will be put in deep sleep when are working. If they are not in use they will be put in deep sleep. But if you do some tests you will notice that is not sense to move some works from one CORE to another and go to sleep the first CORE. Unitll there is a lot of power to use, of course this will do (masks from ITD). After that you will not see anything, the CORES works until they should. In normal Windows state, without any user appliocation (I mean application that USER LAUNCH, not application that system launch). you will see that the Processor use only one or two THREADS (ONE P-CORE) for all the threads in use, and some E-CORES (one or two). The P-CORE in used is called "preferred" and it (they ... 2 THREADS ... with HT) run at full freq. (in my case 5.8 GHz) ... so YES some CORES are in deep sleep and all threads run in one or two cores, but THIS is for performance ... all the threads occupy only 25% the capacity of the single core and so the performance of the core is still at OPTIMUM level, If YOU overload one CORE, what is the sense to "move in" some other task to free another CORE and put to it in deep sleep ? The ITD resolve this for you, dynamically balancing the load. That is the news. And if you are not happy about this, you can affort the use of "Affinity Mask", like I did in the past. All other CORES except the "preferred" are normally "parking". To use the full power I should do a lot of works (32 software Threads that run without sleeping or waiting). The frequency is still high. Only the power is at max value, throttling the frequency. I think is enough to works at the best conditions. Throttle the single frequency of every CORE is better ? Uhmm I' dont' know but I don't think that is right way. But we'll see in the future.

Those are two example about "power" state: the first image is on PL2 (Turbo) Intel processor state, the second is the "heavy load" normal state (PL1). Of course those are from my system. This is a very simple views, other more extensive talks should be done, but I don't think it is the scope of this forum.

In the new(*) Intel architecture (Hybrid like Alder Lake and Raptor Lake), the cores work in different way: the P-Core are for performance with Hyperthreading and high frequencies, the E-core are for efficiency without Hyperthreading and with lower peak frequencies then P-Core. The ITD now makes a good work, and of course if you use more tthreads than the CPU "virtual cores = P-Core*2 +E-Core" the performance is lower (I mean the timing that a simple task do is greater) . If you coordinates yours tthread, you can increase the performance a lot: for example using the "WaitFor...." or a simple "Sleep(x)". Now, in my applications I don't have any tthread that "run" as empty ... all of them are in waiting state. This boost the performance and reduce the heat produced. Some developers are used to create and destroy the tthread every time that they should run, but this of course depends on you works. Take care that some complex AVX2 instructions have terrible times with e-cores and that same AVX2 instructions (not all have the same impacts) used the full resource of one physical core. If Hyperthreading is in use, and for some reasons two Threads of the same Core use AVX2 instructions ... there will be a degradation of performance. I do extensive use of AVX2 instructions (with external libs) and with some of them I should lock the execution (affinity) in different physical cores (or sometimes use a semaphore to execute one or the other). I get AVX2 info from my tests with various hardware, so this is not a "bibble". And I repeat myself, the ITD does a good work now, and may be what I write is not relevant anymore. This is not true (often). Depends about your needs. There are many factors to anayze about that. Like I wrote before, you can run many more threads using some tech. and gain full performance. Take your mind about the power and that the most common factors that slow down the execution are: - the imposed power limit (TDP) which can vary based on various factors (PL1, PL2, PL4 processor states); - processor temperature (individual cores and packages). Do not forget that, unless you use "-F" series processors or external cards, the graphics chipset also produces heat and therefore intensive use of graphics (such as at gaming level) produces heat in the chip. (*) This is a not a new anymore ... the "Arrow Lake" arch. is another baby from Intel ... P.S.: I spoke about Windows platform and 64 bit applications.