David Heffernan

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.

Python multithreading is kinda broken because of the GIL, which tends to prevent scaling. Multiprocessing is the way.

Why has this changed? Is the VCL code custom drawing in Delphi 11 where previously it let the system do it? Or vice versa? Or both custom drawing and the code has changed?

So far as I remember you could not install Win95 on multi processor machines. We'll, you could but only one processor would be used.

Yes it should.

Which is why I didn't quote NT4 ofc

Didn't support multi threading IIRC

How could that be useful? The OS is known to manage context switches correctly.

It's become a somewhat abstract blog post. Because you won't offer details nobody can offer any practical input.

Why would this be useful? It's invariably best to let the system schedule threads. If you are going to do it manually then you probably need to schedule all compute threads manually. Forcing one thread to a specific processor without taking care of other threads in the system will just lead to contention.

Mobile, and Linux (I think) use LLVM. Windows and Mac 32 bit use classic. Not sure about Mac 64 but I'd guess LLVM. Then there's the emulators.... But yeah, it's a mix.

No. I mean what is aDatabase, the variable in your code. What is that? What type.

Just to be clear, what is aDatabase. I suppose the answer could depend on that information.

I just keep a document with every change I make, and then on a new release go and reply them one by one if they are still needed. A few hours work.

Well, we were talking about compiler changes