Leaderboard

You should probably rephrase that "and only slows me down". In my experience laziness always comes at a price. Not bothering to use descriptive identifiers saves a few keystrokes at the price of readability. ARC and GC relieves the developer of having to deal with some of the complexities of resource management, at the price of performance. Etc. I would honestly rather have good performance and full control of what's going on with the resources. Yes. Let's break COM support so we can save some keystrokes.

You appear to assume that this environment will continue to be viable as new versions of Delphi roll out. Unfortunately, the prevailing assumption in the development world is that a) memory is cheap, and b) it is measured in GB. Even without generics, the difference in an application built in Delphi XE and Delphi 10.2 is huge. In the case of a small app of my own, XE produced a 3MB executable, while 10.2 was over 70MB. These numbers are not horrible, but in the context of Windows 2000 treated as an embedded system, I think you are nearing the end of the line for those old systems. You may buy some time by avoiding generics, but sooner or later, you will hit a wall. In a system where your available resources are soldered into the product, you may well need to support a version for those systems which builds in an earlier version of Delphi, and perhaps cannot acquire the same new features as your main application.

Damn, the build server intentionally removes the USE_CODESITE define for the Release, probably to avoid that slipping through. There is V15.0.9.2368 that should behave better. You don't need a complete CodeSite installation. I added a separate download for CodeSite Tools which are necessary if no CodeSite is installed. If anyone has doubts installing CodeSite Tools - just don't do it. You cannot have those logs then.

As far as I know there is not much public information yet. You can visit the site https://embt.co/10-4-Beta, there is a comments-section below the text and the product-management ist answering questions.

FWIW, Windows 2000 isn't supported by the version of Delphi you're using. Also, please read the event log message again. It has all the clues: It isn't your application that is experiencing an "out of memory" error. It's Windows that is experiencing an "out of virtual memory" error. To fix it: Increase the size of the page file. My guess is that the W2K system has a fixed size page file - or no page file at all. Otherwise it would just increase the size automatically - or maybe that feature was added later. I forget. and who cares anymore. If you're really interested in why you get a windows error and not an application error, read some books on Windows internals and the virtual memory manager, or just google it.

We have a maybe ~40k-50k LoC iOS app in FMX for 5+ years and it only ever has had maybe 1 place it specifically needed DisposeOf and/or [weak]. Everything else just uses Free as it supports Windows as well.

I just managed to get 'hello' on Linux 🙂 First time Linux user! so it was a bit intimidating, but with help of Marco's video and google I managed to get it working. First time using the famous sudo command 🙂

I was just about to say that Alt+I is already taken by some other function, because I distinctly remember not setting it for some reason, but apparently it isn't and my memory is wrong. So: Done in revision #3063

ARC! I need coffee for my memory management

I assume you meant "FMX will improve faster without ARC. " But, no, FMX improvements (as in framework improvements) are in no way related to memory management model. The only difference between FMX and VCL code related to memory management is that FMX calls DisposeOf to release FMX components and VCL calls Free. Bottom line, FMX will just run faster on mobile platforms without ARC, but that is it. Other improvements will come (or not) unrelated to the memory management mode change.

Devart, a recognized vendor of connectivity solutions for various databases and cloud services, announced the release of ODBC driver for NexusDB. The driver can be used to access data in NexusDB databases from various analytics, database management and reporting tools, IDEs and programming languages on Windows (32/64 bit). The solution provides full support for the standard ODBC API functions and data types and can connect to the NexusDB server directly via TCP/IP. It also supports multilingual NexusDB databases: Latin, Cyrillic, or Chinese. However, due to the specifics of NexusDB, some third-party tools can connect to the DBMS only in Remote mode. See the third-party tools page in the vendor’s documentation for the complete list of such tools. As an extra benefit comes cost-effective deployment: the driver is a standalone installation file that does not require the user to install or update any dependencies, while large organizations with hundreds of machines can use the silent install method with an OEM license. About Devart Devart is one of the leading developers of database tools and administration software, ALM solutions, data providers for various database servers, data integration and backup solutions. The company also implements Web and Mobile development projects. For additional information about Devart, visit https://www.devart.com/