David Heffernan

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 ......

No point planning for a future you can't see. The real problem was the stupid design in adding Create and Free methods that serve no purpose and confusing so many people. Best strategy is to use a singleton for the context.

You are quite wrong. No point freeing it. No point even creating it.

It's not possible. How could it be?

If the goal is to use RTTI then it seems questionable to use compile time generics. Will result in generic bloat. May as well pass the address of the record and the type info. Or if you want to ensure type safety have the generic method call a further helper method that is non-generic and receives the address of the record and the type info. That avoids the bloat and gives benefit of type safety.

How will you use RTTI with this?

It's a typo. Should be SSCCE: http://sscce.org/