David Heffernan

GetLastError is bad advice. COM doesn't report errors that way. If you would just show a complete, minimal example, it would be easy to help.

If you have 32 bit code that works then that same code will work in 64 bit. We can't see your code.

Automatic header convertors tend not to be very effective in my experience. Don't expect to be able to get a working import unit without human intervention.

You can't kill it reliably and robustly. You can kill it, but expect consequences in your process.

TerminateThread does the job. But do expect your process to fail as a result.

If you have a demo program written in C or C++ then it is easy enough to translate to Delphi. But you'll want to learn some basic C or C++ in order to do so.

You can't do what you ask. You need the isolation offered by processes in order to robustly kill something. You can't kill threads safely. All those other topics that you found that said the same are still a cue.

You don't have time not to read

Any data structure that encodes depth in a static name is surely the wrong solution. Have you read any books on data structures?

What you really want is to separate the iteration over the data structure from the action that you perform on each item. Otherwise you end up with massive duplication of code. Also, this data structure seems pretty unlikely to be the right way to represent any data structure I can imagine.

How do you know that?

https://devblogs.microsoft.com/oldnewthing/20150304-00/?p=44543 https://devblogs.microsoft.com/oldnewthing/20120326-00/?p=8003

Assign to the form's Icon.

As it stands, in your code it will only be inlined in the code in the same unit as the implementation, and only for calls in functions declared after the inline method implementation. You can check this yourself by inspecting the disassembly of calling code.

If you want to terminate the process, terminate the process. Ignore the threads. System will tidy up all the resources, including the threads. Let it do it though, don't you try. ExitProcess does the job.

Not so. You are just as likely to have subsequent errors as the shutdown code in the main thread runs.

I would handle this by using screenshot code that did not hang.

Hmm I did misunderstand. Somewhat tricky algorithm to write down. You need a cursor starting at each end and when they meet you are done. And you reorder the list which may very well be undesirable.

You don't understand. Moving an item to the end leads to all items between that point and the end being moved down. It's perfectly possible to implement this without a realloc and without the dire performance traits of your chosen method. And if your array is huge and push the boundaries of available memory as you suggest, then your algorithm is unspeakably dire.

No, that is not fastest. It can be done with at most N item moves where N is the final coun of the list.

I doub you'll find a single book written in the past 25 years that would advocate nesting over early return. All the most respected experts agree on this and have done for years. Which books are you reading?

We are all given a finite time here. Why would we spend it optimising something that wasn't a bottleneck. Imagine measuring, identifying the bottleneck, optimising, and the observing real discernible performance benefits? How great does that feel? Conversely, imagine expending time on work that yields no benefit. And worse, you likely end up with code that is harder to read and maintain. Usually this just results in bugs. Think of it, you spend valuable time making your program worse. You may as well just go to the pub and leave the code alone. You have a good time, and your program is better. Win win.

What evidence do you have that this task is a bottleneck?

In my world I need to build against multiple different versions of the same library. This is not an obscure requirement. It happens pretty much anytime you maintain development and release branches. When you maintain legacy versions. This is a mainstream scenario in any professional programming setup. Global settings are simply incompatible with that.

Actually, I think that might be right, there is a section in the map file that lists the units in the order they are initialized. Also, there are tons of questions on this topic on SO.