David Heffernan

So you don't mind if the security is easily circumvented?

Although do anticipate that any hacker will be able to see the plain text when you decrypt in memory.

So often this is caused by a defect in your code. You supply an argument that is invalid. Perhaps an object that has already been destroyed. So full fastmm4 debug is useful. You would debug this by trying to create a minimal example that reproduces the issue. That's the starting point.

No reason at all to suspect that multithreading is the issue here. You aren't likely to get good leads from people making random guesses. Hard debugging is the way forward.

The WOL packet is also being routed it would seem.

One of many possible explanations, but far from the only one.

How many ports do you have open on your public facing router?

That's surely not the right solution to the problem. The right solution is to implement the critical code following standard security practices. And to then get it audited by a security expert.

This point about interop has merit, however, Boolean is the wrong type for interop. You need LongBool.

It would have been trivial to solve if only you'd used the debugger. Make it your next mission to learn how to use the debugger.

It's simple. Why write if SomeBool = True then when you can write If SomeBool then It simply adds nothing.

Why is it so hard to reach the conclusion that aUser.Administrator is false? Instead of being helpless here, you can get help from us by providing a minimal reproduction. Easier still would be simply to debug your program. Have you done that?

Never compare to False or True. Instead write if someBool then Or if not someBool then That's not your problem though. Your problem is quite simple. It's the most obvious explanation. You are mistaken, in fact aUser.Administrator is false. It's that simple.

Yeah, modal dialogs and popup are deeply invasive. Find a different way to let the user know.

As discussed above the conditional code simply adds clutter for no benefit. The compiler has already handled the issue for you. Remove the conditional, and let the compiler ignore stdcall in x64. A second point is the use of the export directive. It is also always ignored (a hangover from 16 bit days). Again it should be removed. Therefore the best practise would be to write: procedure MyProc; stdcall; And that's it. Obviously you still need the exports list somewhere.

It depends on the window ownership (aka popup parent) relationships between your forms. What is that in your case?

The ifdef is pointless and wasteless. On x64 stdcall is, like all calling conventions, ignored. So remove the ifdef and leave stdcall there for the platform that it has meaning.

This class can't be used without the compare type being specified.

This seems bogus. Define "really core" please.

You are advocating defining new classes in order to set a single field in the base class. If you can't see what is wrong with that I am surprised. I already said.

OMG, take a poor idea, and make it much worse

Also a false goal.

That's a false goal. Remove that goal from your life. Following it will be making your code worse.

It works. But better to have one constructor that accepts an argument. Think of the time you need to decide at runtime which path to take. Then your way is hopeless.

Ugh, the code you write shouldn't need those ifdefs. That the entire point of you using the libraries provided by others, like Emba. They present a common interface to you. That's the entire point of cross platform coding.