David Heffernan

Show us an example, with modern Delphi. For sure some ancient versions didn't get alignment correct. That's no longer the case. Compiler alignment always works for me, and I do a lot of it. And converting to 64 bit was trivial when I had to do that.

In your Delphi code you should be using {$MINENUMSIZE 4} at the point where you define the enums. An example from my own codebase: //Dragon4 {$MINENUMSIZE 4} type TDragon4DigitMode = (DigitMode_Unique, DigitMode_Exact); TDragon4CutoffMode = (CutoffMode_TotalLength, CutoffMode_FractionLength); {$MINENUMSIZE 1} I would however say that using offset methods to compare offsets is very good advice. But I definitely do not advise manual alignment. The compiler can do it perfectly well. You may as well get it to do that. Then, come the day you move to 64 bit, you won't have to change a thing.

This is bad advice. If you are using aligned records in Delphi, then the compiler uses the same alignment rules as for aligned C++ structs, and for aligned C# structs.

The things you are discussing now seem unrelated to storing pi in a float. I don't feel as though we understand the problem domain yet.

You can't store pi exactly in a float. What is the motivation for the question?

A dfm file is a source file

Definitely not impossible to find the error. Search for TDBLookupComboBox in all the .dfm and .pas files that are compiled.

This isn't true. Your class function calls the default constructor and that performs memory allocation. Free must be called. Instances of classes are heap allocated.

What have you tried so far?

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)