David Heffernan

If it's a char* then no. But if you held the data in a type that also had an encoding then the rtl would convert. Why not convert to utf16 as early as possible though?

Where is the UTF8 text coming from?

Yes they did

Doesn't handle duplicates

Spring has a collection that meets your needs. With pure rtl you can fake it with a geneic dictionary.

If I were you I'd compile the code into a DLL and link to that. My experience is that works more reliably. I used to do the .obj dance back in the day but moved away from it. Very happy to have done so.

I didn't even know that Delphi debugger would step into obj files. How did you compile the .obj file? Where is Delphi getting the debug info from?

I don't really understand this either. I think @PeterBelow was just stating this clearly, and did a good job of it.

The most interesting thing here for me is that the question asks about sorting, but in reality what you wanted to do was efficient lookup of name/value pairs.

Fairly simple to write a function to save the content of a collection to a text file.

Not with the code most recently by the asker. That singleton code is enormously complex, obfuscates, and is certainly not helpful here.

Replace thus with Settings.Free which internally performs that nil check

None of this is making much sense but whatever. More generally I strongly recommend you get out of the habit of using global variables.

Use a debugger, and look at what is in apath. Knowing how to use a debugger is a bit skill.

We don't know what Settings is. How about a minimal but complete example.

It depends on what your external processes do. If you are trying to do something that will be locked down then I guess it will be affected. But calling CreateProcess per se doesn't requires cmd.exe. Unless that's the process that you are trying to create.

Nope, still there, why would MS remove it

Is you real problem that these two strings belong together? In which case declare a record with them in, store them in TList<TYourRecord> and that's the answer, end of story.

Yeah, just try setting a break point on the GetMem function implementation and see how many times it gets hit. I ask again. Does you program use any string variables? Does it instantiate any classes? What is you policy for these heap allocations? Why are you creating problems where there are none?

This is the only place in your program where you use string variables? And you don't use any classes?

It's something of an anti-pattern to call Randomize more than once in the lifetime of a process. Why do you have this call here?

If memory can't be allocated then the message can't be sent and presumably the program stops working? I think your model of avoiding try is probably very flawed. You are about to call PostMessage which has a kernel mode transition. Your try is not the hot-spot in this code!

Instead of us guessing, it would be more productive for you to boil this down to the simplest example that reproduces the issue.

Hard to know why this is happening with the information we have.

Because when memory allocation fails it's very hard to recover. Also, you don't control the allocation for strings. The rtl does that. You'd need to redesign you entire program to work with low memory scenarios. The entire rtl/vcl etc. is not designed to work in these scenarios.