David Heffernan

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

Slightly smaller executable files, binary literals, literal separators, support for new asm instructions. I think "care" feels a little strong.

I should have been clearer. I'm talking about the new code they added for themed apps. I agree it is necessary for old pre comctl32 v6 apps. I still do that. For comctl32 v6 I can't understand why they don't use PARGB32 images.

It has always been a mistake for Embarcadero to owner draw menus when they have images. I modify the rtl to avoid this and let the system drawn the menus, using PARGB32 images. After about 4 or 5 delphi releases they got their owner draw code to mostly work as well as letting the system draw it, although I think there were still DPI scaling issues. But it was inevitable that a new version of Windows would mean that owner draw code needed updating. And any applications out in the field would be stuck with this owner draw code that hasn't been tweaked for the new Windows version. It makes no sense to me that they did this. Surely the entire point of the system theme is that the system draws it.

Perfect for making images contain partial faces!

For 32 bit it's just Get8087CW and Set8087CW, but your real problem is still identifying the specific point in the code where it is changed.

This isn't to do with project settings. These settings are owned by the thread and something is changing them. By the sounds of it that something is an external DLL. If so you need to save the fp control word before you call the dll and restore that saved value when the dll call returns.

It has been demonstrated this is only possible using include files. I'm not sure what you can expect to find in a book that can add to this knowledge, and I doubt very much that ALL CAPS is going to unlock any blockage. Perhaps more likely is that what you are remembering was how to split something other than interface and implementation parts of a unit.

I'm sure you can do this easily enough with tools like obs