Leaderboard

... which is kind of the definition of "cooperative".

I'm not on a Dev machine but there are 2 modules: 1) to show shortcuts and another 2) to change the IDE shortcuts - both I seem to remember have Keyboard in their names.

I heard that he is starting every day over!

I inherit most of my classes from TObject (I have a habit of freeing what I create myself) and ALL of them have inherited calls in constructors and destructors, even if the Create was ReIntroduce-d. There are a MINIMAL amount of cases when this was strictly forbidden - there I did the same what @Dalija Prasnikar did - put it there, comment it out, put a comment why it is commented out. With links, if possible. These just feel empty without inherited calls, even though I know they do nothing. On the other hand, my OCD makes me capitalize almost every instruction (Create, If, Then, Begin, End, Procedure, Function, etc.) so it might be just plain stupid after all 🙂

From your link: (emphasis mine) So that would mean Windows 95 had preemptive multitasking for 32 bit programs. I'm not sure though, I never really used it. Windows 3.x used cooperative multitasking for Windows programs, but preemptive multitasking for DOS programs. Of that I am sure because I used and programmed for it.

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.

I found Delphi 11 compiler also generates faster code. By re-run the Delphi test code for calculating 50000 digits of Pi, https://talk.remobjects.com/t/updated-benchmarking-oxygene-island-versus-delphi-c-c-and-net/19499 I found for the same Pi-Calculation code, Delphi 11 x64 - 31.684 sec, 6.2% speed improvement (over Delphi Rio) x32 - 33.880 sec, 3.2% speed improvement (over Delphi Rio)

Most likely this: https://quality.embarcadero.com/browse/RSP-30870

Come on what about the way they've changed the high dpi support (it's almost working.).

Not yet, because I don't have D11 installed to generate them. But anyone is more than welcome to submit a Pull Request to contribute them. Agreed (or at least rename the folder, in case you need to recover it later). That is usually the first thing I do when I install a new IDE version, and then have my projects point to the latest Indy repo source.

The latest version of Indy 10 (https://github.com/IndySockets/Indy/) supports back to C++Builder 5, and can officially use OpenSSL DLLs up to 1.0.2u (for OpenSSL 1.1.x+, use this WIP code). TLS 1.2 has been available in OpenSSL since 1.0.1, and Indy 10 has supported TLS 1.2 for a long time. OpenSSL DLLs are available at https://github.com/IndySockets/OpenSSL-Binaries (https://indy.fulgan.com/SSL/ is retired). If you are getting errors from Indy's standard TIdSSLIOHandlerSocketOpenSSL component when it tries to load the DLLs, then you are likely using DLLs that are not compatible with your version of Indy. You can call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why the DLLs are failing to load.

I would leave the bundled Indy, and the global library search path, be and instead add the Indy repo as a submodule to the project repo and add the local path to that submodule to the project search path. Of course that only works as long as the design time properties of the bundled Indy and the one in the Git repo are compatible.

After I updated my phone to iOS 15.0, the apps that were already on it, compiled with Delphi 10.4.2 using iOS 14.5 SDK, ran without any warnings. Xcode 13 is now installed, and I was able to import the iOS 15.0 SDK. EDIT: As per this report on Facebook: https://www.facebook.com/groups/137012246341854/posts/4389107827798920 App Store builds using Xcode 13 FAIL. Dev builds are OK. I'm looking into why the App Store build fails EDIT 2: App Store builds work if Release config is selected. I'm pretty sure that in earlier versions of Xcode, it did not matter if Debug config was used. A word of warning about installing Xcode 13: When I used the App Store app on the Mac to update Xcode, it spent a couple of hours "stuck" at around the 95% mark. I ended up restarting my machine, and it went back to around 75%: I waited another hour or so, and it did not move, so I gave up, and downloaded Xcode 13 from the developer site: https://developer.apple.com/download/release/ The link to the released version of Xcode 13 seems to have disappeared from that link at the moment - hopefully it will re-appear. Anyway, I made a backup of Xcode 12.5.1 in my /Applications folder first, and after downloading Xcode 13, opened a command-line window and executed this: cd /Applications sudo xip -x [path_to_download]/Xcode_13.xip Where [path_to_download] is the path that I downloaded Xcode 13 to. This unarchives Xcode 13 into the /Applications folder. sudo is required for permissions to unarchive to /Applications

Nice in theory, not really doable though - they are all so different because we all have different ideas.

Should as in "it would be desirable" but the Delphi compiler does not do that. This is usually achieved by compilers by either automatically inlining calls and then noticing there is nothing in such call hence no call/code to emit at all or by applying WPO or LTO. Both are things the Delphi compiler does not do. The Delphi compiler does not inline inherited calls if the method is virtual which Destroy is.