David Heffernan

What specifically do you mean by "help me translate"

6 month contract and you have to jump through all these hoops. It's a seller's market right now.

Staggering that an employer could post something as demeaning as this.

Next release of Python supports per interpreter GIL which sounds exciting.

Well, there will be an error code. You have to retrieve it.

When you tried this, what happened? What error was reported. Or was there no error reported?

This is precisely what I am doing. My Python build code to perform signing starts like this: def Sign(filename, sdk=None): # see https://medium.com/@joshualipson/ev-code-certificates-automated-builds-for-windows-6100fb8e8be6

It doesn't look like that to me. It looks like a file read for a file named by UNC. I don't think I'd be wanting to use FileOpen anywhere ever. Shouldn't you be using streams these days? Having said that of course, FileOpen still works. You didn't tell us what happened when you used the old code. If you have a problem that you want some help with, then you should say what the problem is. People can't offer solutions to problems that aren't described. Do you understand what \\IP_address\FolderName\Filename is? I trust you do, and that the file specified by this UNC path is available on your current target device. Is it?

For the record this is completely wrong

You said a C# project. Anyway, why don't you do this work yourself?

That will maybe buy you 30 minutes of a qualified person's time.

Hire a programmer

That's not quite enough. Do the exe and bpl both link to the same runtime packages?

This will work fine so long as everything is linked correctly. No need even to use stdcall. So probably the linkage is messed up. We can't see the entire picture.

To cast to PByte then it's PByte(myPointer)

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.