David Heffernan

Whilst this is true, one should not be complacent and rely on it. A skilled hacker will have absolutely no trouble hacking your Delphi app if it is poorly designed.

Tampering with executables is pretty routine, and can be done for pretty much any program irrespective of the language it is coded in. The real question here is why the target was running a tampered executable in the first place. That seems like the real source of the problem, not that the original executable was written in Delphi. If your new customer thinks that the problem will be solved by writing programs in "safe" languages then he/she is delusional. Once you let an attacker execute their code in your computer, the game is over.

If the tool was clever it would only object when the parameters were both passed by reference

There's no silver bullet here. You have to find every call that can potentially change the control state, and restore it when that call returns. Plus you've got the broken Delphi RTL which means that a change of control state in one thread can leak into another thread. It's worse on x64 than x86. I've discussed this here many times before. Emba know about the issues and have chosen not to address them. I've told them how to fix the issues in the RTL. In my code base I've replaced a number of RTL functions with thread safe versions, and added protection for whenever my code calls into external libraries. No silver bullet.

Could be all sorts of things. Calling almost any external module could change the control state. It's very hard to track it down.

Round is deterministic. Remember though that its input is its argument, and the floating point control state.

That would then be a race condition between the copy and the modification. That seems like the far bigger issue.

Nothing to see here. Carry on using const for string parameters. The issue is vanishingly rare. If you encounter the issue, fix it. Don't go changing existing code unless you are actually affected by the issue.

Not so. In fact set of Char is actually implemented as set of AnsiChar. It has very special treatment introduced to "help" porting from ANSI Delphi to Unicode Delphi.

Is your question, "is it possible to change the focus without changing the active window?"

Unfortunately Emba never implemented proper generics support for sets which would make this trivial and type safe.

The issue is that you need to write this code for every single set type that you use.

There is another issue here, which is that you check bits that are unused, it the base type has number of members not divisible by 8. Probably you get away with it because it's probably hard to get 1 in any of the unused bits in a set.

Thinking again, the specifics are important here, the use of an untyped parameter that is overload with an absolute variable. This basically renders range checking close to useless, because of the unsafe typecast.

That's wrong. The code reads absolute aSet rather than absolute aByte. Consequently this statement is also incorrect. aSet could be on the stack, or the heap, or a global. In any case, I took the question a bit more generally than you. Accessing arrays out of bounds can lead to AVs or corruption of other memory in the case of a write operation. Yes, I know that the example here is a read. I was generalising.

Behaviour is undefined. You might get an AV, or a write might corrupt data. Definitely not graceful failure.

Your code doesn't load a dll. You have an abstract virtual method that is never implemented. You are trying to run before you can walk. You aren't going to learn anything useful this way. You need to go back to the basics.

Enumerate the members of interest and persist them. If these classes are really that simple, what is the difficulty? What are you stuck with? Using the RTTI? Or working with INI files?

Talk to other people and see what they want.

This was from the original post. I suspect you meant to say fragmented rather than defragmented. When I asked how you assessed fragmentation you said that you hadn't, and that you didn't understand virtual memory. I don't know what you think you have demonstrated, but I don't think you have demonstrated anything at all.

What's the point? You've already reached a false conclusion based on a flawed investigation. If we try to point this out you tell us that you aren't interested in learning the truth.

Why aren't you curious to learn about how virtual memory works? Why aren't you curious to learn how sub-allocating memory managers work? Why aren't you curious to learn what address space fragmentation is?

I understand that you'd like that conclusion. It would be nice if it were true though. It isn't.

If you don't know about address space fragmentation, don't you wonder whether or not it is relevant?

Are you measuring address space fragmentation?