David Heffernan

No idea what type myPointer is. A simple 10 line program would reveal all.

Code is utter shite anyway. Just cast @InData to PDWORD and use pointer arithmetic already. I would imagine that FixInsight would give the warnings you want.

Every time you cast a pointer to a 32 bit integelral value, you are truncating. This is 64 bit porting 101. longword(@InData) That's truncation.

I thought they'd been removed because they weren't useful. They were added for SQL server and in the end it turned out they weren't useful for that application.

I'm baffled. Both of these statements are wrong. Delphi is known to be produce very poor and inefficient code. Although I'm not qualified to comment on FPC's code gen.

Yes. Probably the easiest way is with UnmanagedExports but it can also be done with COM. You may need to create a wrapper C# DLL to bridge the interface.

Looks like your json parsing code is wrong but you didn't show any code. Very hard for us to say what's wrong with your code when we can't see it. Don't be shy.

Exactly. Why reinvent the wheel? And if you absolutely had to implement VPN in Delphi code, then hire an expert that has implemented VPN before.

Using TArray<T> is better because it doesn't have type compatibility issues like this. It makes it easy for different libraries to interop. Because the different libraries don't need to know about each other and declare types in a shared unit.

This doesn't seem to hang together. Could you provide a complete program to demonstrate the issue. I get that if you need to support pre generics versions then TArray<string> is out but if you don't need to support those ancient versions then this for is much preferable.

I didn't see that condition documented. I also hadn't realised that some streams can read fewer than the requested bytes but there still could be more left. That does seem a strange design choice. If you can wait for at least one byte then surely you can wait for all requested.

I not advocating the repeat. I think the TryRead is nice. Class helper for TStream would be good. I general TryXXX methods tend to be useful in loads of places.

Weird repeat loop. I'd do: repeat BytesRead := Stream.Read(Buffer, BufSize); until BytesRead < BufSize;

It's because the second arg must refer to writeable memory and UniqueString ensures that. A websearch on CreateProcess and UniqueString will yield many discussions of the issue.

At this point, you probably need to sort it out yourself. You seem to have decided to take an approach that won't work. Given that nobody can make it work, you need to come to that realisation yourself.

Why are you asking the shell to create a cmd process which in turn creates another process. Use CreateProcess and miss out the cmd middle man.

Seems like a good place to start. Why keep asking here if when the answer comes, you don't heed it?

So what is the question?

WinProcs? Why are you working with code from the 1990s? Where did that code come from?

Is this a minimal do nothing program? Or is your actual application logic there?

Likely a defect in your code. You'll need to start debugging.

There will be other calculations where that isn't the case

Floating point can be tested for exactness too. Your idea of doing floating point calcs and then rounding to 4dp before equality testing is still subject to issues. If there are differences after the floating point calc, then the round to 4dp could fall on different sides of the rounding boundary. Always in these discussions there needs to be more specifics of the calcs involved.

Why would you be calling power and then truncating to 4dp and comparing for exactness?

Seems like bad advice. Why would you do this?