David Heffernan

Doesn't this suggest that reducing the amount of heap allocation would lead to much bigger gains?

My point is not that it's a 32/64 bit issue. My point is that it could be a difference in the way the C code is compiled.

Is it possible that the difference is due to the PCRE code being compiled with poor settings? Something similar to this: https://stackoverflow.com/q/27821277/505088

My understanding has always been that debug dcus are compiled with optimisations etc. and so there should be no performance difference. Can you provide a cut down program that demonstrates the issue?

Usually in this scenario one would prefer to get on with the job rather than spend time explaining the issues. I'm sure that if @dummzeuch would like some help he know how to ask.

You just have to extend the code to bring itself out of the tray as you say. Although strictly speaking it isn't in the tray and in fact the tray isn't even called that. It's a notification icon in the notification area. What you mean by being in the tray is that the main form is hidden, Visible is false. So you just need to show it. Presumably you already do that when the notification icon handles being clicked.

You write a zero byte beyond the end of the char array. Solve the problem by using Move to perform the copy.

GitHub is not a fork. That is the master repo.

What is XE10?

Why wouldn't you get the latest source from the repo?

Scale it back to a small test program. As for what's wrong, the thing that keeps the window on top is the window owner property. In VCL that's known as popup parent. I know you want a quick answer but sometimes you have to work a bit. Make that minimal test program and the answer will be easy to find.

This doesn't make a lot of sense to me. Why would anyone want to use some random files whose history we have no knowledge of, when we can simply checkout the source from the repo and use it directly.

What you are looking for is the default behaviour. Clearly there is something in your code that changes this. The solution is not to ask for some new code to make this work for you. The solution is for you to remove or fix whatever it is in your code that has broken this behaviour. Start a brand new VCL app. This will come with a main form. Create a second form, and show it. Note how the second form can never be behind the main form.

Download the source from the repo and include it in your project

Compiler warnings, rather missing the point

Bug in your code. The inliner has no reason to pass any parameters because you told it the external function has none. If you want to use inline, and doing so removes the jmp leaving just a single call, then you need to declare the external function correctly. I think I already told you this on SO.

In C++ you can prevent it from happening.

This is still an enormous weakness in the language.

It's fairly clear that the Delphi language we are referring to was designed to make such types assignment compatible. That is made clear by the documentation for the Delphi language. There are other languages that have taken different approaches, but we aren't discussing those languages here. We are discussing Delphi. Whilst you might wish that a different decision had been taken, it wasn't. It's really not likely to change.

But the language was designed differently. Use records. What's so difficult about that?

Since the language regards these two types as assignment compatible, it's pretty hard to imagine adding warnings or hints when you write such assignments. Wrap the value in distinct record types.

Fair enough.

You'll need to declare two record types for this. The language isn't going to change now.

@Stefan Glienke And the existence of two byte data that cross cache lines shows that unaligned access is not atomic. When arguing about non deterministic properties like atomic access or thread safety the language used is a little different. When we say code is. It threadsafe we don't mean that it will always fail. We mean that we can't guarantee that it will always succeed. When we say memory reads are not atomic we don't mean that they won't always be read with multiple bus reads. We mean that we can't guarantee that they will always be read with a single bus read.

You agree then that unaligned access of data greater than a single byte is not atomic?