Cristian Peța

You are right. I'm using Sleep() only in Windows services in the ServiceExecute(). 50 or 100 ms is not an issues for a service to get down. And checking Terminated, an increment and loop every 50 ms is nothing.

Use Sleep() in the thread and start other threads at that interval. The thread with the Sleep() will need to have highest priority.

If you have a timer there is a possibility that your execution will not end and a new one will need to be started. With Slepp() this can not happen.

What is wrong with Sleep()

Into the Execute you need to have a code that will not exit till you need that thread alive. procedure TMyThread.Execute; var LHowMuchToWait: Integer; LDoExit: Boolean; begin try repeat ExecuteMyClass(LHowMuchToWait, LDoExit); Sleep(LHowMuchToWait); until LDoExit or Terminated; finally Terminate; end; end;

Now I see that FieldData can be defined for max 256 fields. FieldData: array [0..255] of PAnsiChar; And get rid of setting the length of FieldData for every field. uDBF.pas

Sorry, uploaded wrong file... uDBF.pas

I suppose is about the algorithm (google for "Dragon4 algorithms").

I used FieldData array to store offsets instead of FData that must remain 4 bytes. Maybe there are better approaches but it was faster so. This is a fast patch and not optimal. uDBF.pas

It is working like compiled in D11.1 if you disable ASLR from linking options.

FData : DWORD; And should be 8 bytes on 64 bit. Something like PAnsiChar. Fields^[iFieldCount].FData := DWORD(Data + iTmp); It is wrong to cast to DWORD for 64 bit.

Do you have thousand record types? Then you have some work... If there are not so many record types and you need to use both 32 and 64 bit versions then I would make for every record an old version that has Cardinal instead of pointer just for reading from and writing to the stream. And two procedures to copy data between old and new record. The old record with Cardinal will be used only to stream data. If you want to do more then use old records with Cardinal instead of pointer only for reading. And save data in a new format like JSON.

ftString size is default to 20. If you want not to set the size then you can use ftMemo.

Intel VTune with map2pdb

With pointers like Alexander suggested or an array or records.

If someone do have an issue that is possible solved in latest commit why not trying? I can't think that an commit is made without testing first.

Have you checked https://github.com/pleriche/FastMM5/activity?ref=master ? Latest commit is 6 nov. "Handle a potential race condition in FastMM_DetectClassInstance: If another thread frees a block while it is being evaluated as a potential class then an A/V could occur. This indirectly affects other functionality, like FastMM_LogStateToFile." You can download sources if you don't use git to clone repository: https://github.com/pleriche/FastMM5/archive/refs/heads/master.zip

Windows or something else? You can try to delete .dproj and see if that helps.

This is all we need to reproduce? Can you reproduce in a small test project?

Personally I wouldn't buy Windows ARM because incompatibilities. 20 hours without charge is nice but is not a must have for me.

Apple is giving you no choice. With Windows people can choose and there are not so many eager to embrace this change.

Maybe I'm wrong, but CopyDataSet doesn't use ArrayDML. Only if speed matters.

Delphi 11.3 I have a project that when built for Debug Win64 the blue dots are where there should be but when I run with debugging the blue dots are shifted upwards and do not stop if I put a breakpoint. For Win32 is working as expected. All other projects I tried do not have this issue. First image is before run, second is after run. The blue dots are how they should be but shifter upwards. I tried to delete and recreate again dproj file. Same behavior. I checked and endings are with CR-LF. All units in the project are affected. The shift is more or less upwards somehow depending on the unit size. Same units (files) used in other projects do not have this issue. Issue is linked somehow only to one project. I appreciate any advice.

Probably something went wrong with first attempt to recreate dproj file. I tried again to delete it and now debugging works for x64.

Thank you. In this project I have included units from packages that for sure are not rebuilt for x64. Building the project works because I have included all the files from packages but there are old .dcu files from building the packages. Will try tomorrow to rebuild all packages also for x64. Usually I'm doing this only for x32. I need to debug for x64 because it behaves different from x32 and debugging with messages and so on is so painful and slow.