David Heffernan

Why do you care about these tiny differences in these tiny executables? If you care use Delphi 5.

All these marketing people trying to generate buzz around a name. How about fixing the bugs and making the product better? Then you can call it anything you like and it will sell.

There's a what's new that you can read, and there's not much there in my opinion.

The fix the actual problem. Otherwise your security is broken.

I don't think this is possible because there's no good use for such a feature

Really not enticing me to click on this link by posting in a huge font with no summary or commentary.

This sounds like a really interesting numerical problem! I suspect that in practical terms, sorting is going to be the winner though.

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Declared_Constants It's all in here

I'm quite excited about escaping GIL tyrrany but shared global state in the python extension module I develop is going to be tricky. I'm looking forward to seeing what you've done here and drawing some inspiration!!

My recollection of Lutz's work is that Learning Python is the book of his to read. As for the Python 2 vs 3 distinction, I'd be less worried about that. That's more about syntax details than concepts. A really good work written for Python 2 is better than an average work for Python 3. The differences between 2 and 3 aren't significant conceptually.

Python is very good at managing change in my experience.

Well I'd not want to use rtl code to convert float to string anyway because it doesn't get it right for all floats

I've seen other reports similar to this. It smells like an emulator bug.

Why would that be? Would it be because you asked a technical question without offering any details. Using more threads than processors can be effective when some of the tasks aren't CPU bound. A good example would be writing to or ready from disk. Accessing memory as the task I would not expect to be amenable to using more threads than processors. Usually computers have greater peak CPU throughput than memory throughout. So if the work is purely memory access then I'd expect CPUs to be idle. Because the memory access should be the bottleneck. You are quite right when you point out that nobody can advise you accurately without knowing your precise needs.

Just use thousands of threads and get results yesterday, simples. No, if you use too many threads then your will get results slower. How do you even think computers work?!!

There won't be a problem, but it just won't be efficient to use more threads than processors. My question for you is why you want to do that?

Depends what the threads are doing

You can't suggest that without knowing what the numbers represent.

It's as necessary as it always was if you are using a pre Unicode Delphi. And yeah it's still around. Code doesn't vanish. Why would anyone develop it for compilers that aren't developed??

Most of the tnt components map cleanly to standard vcl components iirc

My take on this is that you want to start making changes in your Delphi 7 code base that don't change the meaning of the program there, but mean that it will compile and work as expected in both ANSI and Unicode Delphi. In an ideal world you'd be able to do all that work preparing for the switch and reach a point where you can compile with both ANSI and Unicode Delphi, and the program works the same. Then you can cut the chord to Delphi 7 and commit to Unicode Delphi. Then you do the second piece of work which is to get the code working on 64 bit.

That blows my mind!!

Sounds a little implausible

Obviously Microsoft's header files handle struct alignment correctly

Signing would help