David Heffernan

Maybe you need to get a programmer on your team? 

Why not do this yourself? You could get some AI help to start, and then polish it up. 

If you want to pay somebody to do this there are plenty of online sites dedicated to facilitating that. 

7 hours ago, Dave Nottage said:

I believe the change to the types was related to C++Builder compatibility

This looks like the tail wagging the dog. 

One thing I find odd is that you feel the need to change the behaviour of basic windows API functions. Why are you doing this? 

7 minutes ago, sp0987 said:

They will probably be still using the core sysUtils with original functionality

No. You detour the sysutils functions and all code in your process is impacted. 

8 minutes ago, sp0987 said:

Is there a way (place in Delphi) we could easily (without recompiling RTL/VCL) override the few sysUtils's functions?

Yes, detours. 

47 minutes ago, Lajos Juhász said:

First step is to create a backup of the original dproj.

This isn't going to be necessary because it will be under revision control

Is it possible that your installation has been corrupted. Why would there be Android files under Win64?

13 hours ago, DelphiUdIT said:

Like I wrote, I don't use swap file and I don't have any issues, except the performance (little loss). May be, with Windows 11 that is not a problem, but the software works perfectly in this way: next time that I'll refactor it I'll try to retest all.

If you aren't using a swap file, where do those pages go when removed from the working set? I mean, these are pages allocated by your process. 

My best guess is that you did a benchmarking exercise that reached an incorrect conclusion and then you have continued using this function erroneously. 

2 hours ago, Brandon Staggs said:

Rather than editing SysUtils (and having to keep your changes up to date every time you upgrade Delphi), Detour the function calls you are concerned about:

If you can do this with detours then it's preferable by far

How are you measuring the performance degradation?

14 hours ago, sp0987 said:

We need to modify all sysutils date time functions

Why though? 

Nobody really cares that much. It's a gruesome way to go. I'd solve the problem properly but you don't want to tell us what the problem is. 

So why would spending the time to do this be better than letting the system do it on demand?

10 hours ago, DelphiUdIT said:

Yes, you're right. There is a little latency (in my application measured in 10 milliseconds near) when the program start again to works and use (allocate) memory.
But whit this, I can maintain the memory free, especially when a lot of gigabytes are used.

This just makes your program slower though. Forcing the pages out of memory and onto disk before other programs need that memory takes time and can only lead to performance reduction. 

You may as well open the computer up and remove some memory sticks! 

EmptyWorkingSet removes pages from the working set. Doesn't this mean your program won't be able to take advantage of memory caching? 

What you seem to be in denial of is the need to recompile every rtl/vcl unit because you made a significant change to the interface of SysUtils. 

Are you really prepared to recompile everything? 

I bet there's another way to solve your problem. If only you'd tell us what the actual problem was.

You are debugging the host. You need to debug the DLL.

c++ - How to debug a DLL file in Delphi - Stack Overflow

Rather than linking to files, please show the code inline, formatted 

You can debug the dll, assuming you have the source code

1 hour ago, Die Holländer said:

Ahh, a typical reaction that started in that time..

 

My Commodore 64 is much better.

My Apple is much better than your Windows

My Iphone is much better than you Android phone.

My Javascript language is much better than ...

Well, the Speccie and the 64 did have better games. The 64 had epic sound. The beeb was more used for hobbyist coding then the other computers of that age. And the beeb did have by far the best programming language of these. There were real differences. 

10 hours ago, msi1393 said:

I did this but it didn't work

We still don't know anything about your dll. When I said that nobody can give you any step by step guides without knowledge of what the dll is, I stand by that. I mean, we could write you lots of hypotheticals. You've got one above. But how about you put some effort in and find out what this dll offers. 

On 4/26/2024 at 12:04 PM, Cristian Peța said:

ZX-Spectrum BASIC was like an easier assembler where you use CALL and RET (Z80 assembler).

Speccie basic was a terrible language. The beeb had a much better variant. 

18 minutes ago, RayTmsk said:

What about topic question?

Well, knowing what you are doing in the setter functions is likely important to decide how to write them. You want to take copies? And do you have one member field for each array type? 

Anyway, I'm also of the opinion that a branching generic method is little better than a series of overloads. 

There are lots of different ways to do this depending on what the dll offers. Nobody can give you any steps without knowing how the dll exposes its functionality. 

2 hours ago, RayTmsk said:

procedure TDataField.SetAsGuidArray(SourceItems: TArray<TGuid>);
begin
  DataType := ftArray;
  FArrayItemType := ftGuid;
  FDataArrayGuids := SourceItems;
end;
 

Are you sure this is right? It takes a reference to the array rather than a copy.