David Heffernan

That's not true, and not helpful. The function can return anyrhing it likes. No reason where there has to be a field anywhere whose value is returned.

Somewhat ironic that the output that performs worse is the one that you found impressive.

C++ compilers are generally far better at optimisation than any Delphi compilers

When facing terminology that you don't recognise I cannot recommend the use of websearch highly enough. https://enterprisecraftsmanship.com/2016/07/27/what-is-an-implementation-detail/ https://stackoverflow.com/questions/1777719/what-is-the-definition-of-an-implementation-detail And no, it's the second excerpt that relies on leaking implementation details, which is why it should not be used.

Time to stop digging.

That's not nonsensical from the programmer's perspective. Only from the constraints of the language design. I'm coming at this with an open mind as to what a programmer would like to be able to do. You are tied down by the historical precedent of syntax. The fact that [1,2] can be an open array constructor, a dynamic array, or a set, depending on context is the root of the problem. It is that poor design of the language that is at the root of this question. So I object to your defence of the language and assertions that what the programmer wants to do is nonsensical. I struggle to understand these two claims of yours: 1. A plain function is a better way to implement an equality test than an operator. In my view that is an indefensible claim. You have to use a plain function because the language syntax doesn't support an operator. But that doesn't make the operator undesirable. Just unachievable. 2. An operand that is an array implies more than two operands. I can't work that out. That's why I though you don't know what a vector is. But you seem to have got past that in your last post where you happily use arrays as operands.

It's almost as if you don't know what a vector is.

Even on windows, IsDebuggerPresent is not the same as System.DebugHook <> 0. The former tests for any debugger, the latter tests for the Emba debugger.

An array can be thought of as a single entity. Consider vector arithmetic. Take two vectors of length N and sum them. That's one operator, two operands, each operand a vector with N scalar components. My entire livelihood is based on such a form of mathematics. Are you saying I've been doing it wrong?

There are only two functions, the A and the W version. The A version converts the input text arguments to Unicode and calls the W version. That's always the case with Windows. The A function is just a time and memory consuming wrapper around the W function. Note that this implies it makes no difference to the output of the created process since the W version is always going the work in the end. Basic rule is always call the W version. It's more efficient, the system is Unicode natively, and the W version means your code can be used by non English users.

You see Chinese text when you expect Latin text if you interpret 8 bit ANSI text as though it were UTF16 text.

So far as I can see, EXE packers bring cons but no pros. They are simply tools for making your program worse.

Dude, an array doesn't have to mean a range of operands. An array can be viewed as a single thing. Also, it's entirely possible to imagine useful operators with more than two operands.

It doesn't seem to me to be stupid to want to use arrays and operators together.

You must have all the versions that you use, so you can answer this by inspection.

You can tell it must be stdcall since that is the only convention supported by classic VB.

I know I go on about this but it's really important, in my view, to stress that the testing framework doesn't discover the bugs. It's the developer that writes good tests that discover the bugs. You need a testing framework to help manage the test code. But the strength of the test is always the quality of the test code rather than the framework. There are plenty of libraries that ostensibly have test suites but are full of bugs because the test suites are incomplete.

What about the people who you are asking for help? I would post on one site first, and if you don't get a good response, then post elsewhere, with link to the first place.

There are no newsgroups here.

The curse of cross posting ......

That's exactly what I suggested if you read on to the second paragraph.

That SO topic is the same issue as yours. You might have to do a bit of research starting there. What you need to do is find the child process that actually implements the app. Lots of code examples to do that.

That's the name of the executing process. Asker wants to know about external processes.

Well, nobody really knows what that is. But your question is how to find the name of a UWP app from a top level window handle. Which is a question asked here https://stackoverflow.com/q/32001621/505088

So I guess you are happy to rely on the left to right order ......