David Heffernan

It's plausible that Indy isn't the problem here and that a wholesale library replacement will leave you with the same problems.

Does vtune do code coverage?

That's kind of odd. Does the same happen if you do this with a brand new vcl project?

@Stefan Glienke You could readily tweak this to work with TStrings rather than TStringList and avoid all that hacking at the internals. But it's nice to see you using records for enumerators!

Not all of us do this!

This would be too late to make much difference. The longer you leave bugs the more they cost. And I'm not sure that it would even help much. You'd have to devote significant resource to running the community contributors. Better to use that resource to get the quality right from the off. There's just something rotten in the Emba development model.

Python has enumerate for this which ought to be possible for Emba to implement for Delphi in a similar manner as for in.

The thing is, releasing software that is of low quality means that your engineering team spends large amounts of time addressing this low quality post release when it is much more expensive to do so. If they would use better engineering processes and concentrate on quality from the very start, then they would use far less human resources. They aren't even cutting corners with this approach. It is inefficient in terms of their own times and resource, and obviously really inefficient for every user affected by this low quality.

Or better, a helper to TStrings

You'd think that a good engineering department would be able to develop programs to a sufficient level of quality that you wouldn't need the public to do the testing by trial and error. I don't agree with the sentiment here that it is not possible to create good quality software without getting the public to test it.

Not an anti pattern

All prior experience tells us this is what happens with a new release. Now they spend a year or two fixing this round of bugs. We'll, fixing the most significant ones. Some will be with us for a while.

Is it the calculator window that you want to bring to the top, or is this just an example? And what if there are multiple windows so named?

That all makes sense. However, I still think I would use a resource for this. I do something very similar myself. I my case the executable is a help browser, and the embedded data is zipped up webhelp content. There are windows API functions for updating resources.

Yes. This isn't really to do with Delphi. Writing to a file can be done in any language. Certainly I can see that antimalware software is likely to object to such code. I could image attaching a payload to an executable after building it, and I'd always do that using a resource. But I'd see a problem with an executable being modified in the field. That would make updates next to impossible. File versioning would be messed up. What data are you adding to the file anyway? Why are you doing this at all? And when you say arbitrary executable file, I presumably mean an executable file that you control. You can't really imagine doing this to executable files provided by arbitrary third parties?

You should try one of the compilers other than the 32 bit Windows compiler!! I 100% agree with the sentiment that the tooling should work.

I think this isn't the way to do it. I'd expect to see you add a resource with the additional payload.

Doesn't an exe contain a file hash? I'm pretty sure that there are better ways of solving your problem, whatever it is, than modifying an exe file.

Even if you can succeed in writing to this file, what do you think the resulting exe will do?

There are many posts on this topic on Stack Overflow. What did those posts yield?

With all your experience you shouldn't be surprised when people wonder if there are better ways to solve problems people face. I'm sure you do the same in your work.

The OS already has UI to let you switch connections on and off. Why not use it?

Have you considered blogging?

It never was ever. You are probably misinterpreting memory stats from a task manager program.

Certainly in the case of R it has a *nix heritage and is well supported on *nix and Windows platforms. Multiprocessing has always been the primary way to do parallel processing on *nix so it's entirely reasonable the R is single threaded and also reasonable that this has not got in the way of its success.