David Heffernan

I don't see why there should be compromise. I want great tools and efficient code output.

It's entirely possible to have a compiler that is fast during development / debug builds, but takes more time to optimise for release builds. So much Stockholm Syndrome in Delphi-land!

Binary compatibility for packages isn't something that bothers me. I mean, you get a major new upgrade and that happens anyway. But better code gen wouldn't mean changes to binary compatibility for packages. Also is 11.3 even binary compatible with 11.2 packages? Why do I want a single pass compiler? I'm not the end user. I want to deliver a program that runs quickly. Am I going to tell my customers, I don't want to deliver a program that runs twice as fast because then I wouldn't have a single pass compiler. Why do my customers care about single pass compilers? Is that something that your users talk to you about?

Frustration at my dev tool lagging behind. The editor is the least of my worries. It's the poor and never changing performance of the code emitted by the compiler that frustrates me the most.

What about for your 64 bit compilation?

I guess my sarcasm didn't shine through

If only other editors had this feature

The fact that you have a different workflow from me doesn't mean my workflow doesn't exist

The problem with this is imagine the following scenario: 1. You release version 1.0 of your software with Delphi 11.2. 2. You then make a fixes only branch for version 1.x that only gets quality / bug fixes pushed to it. 3. You continue main stream development for version 2.0 and decide to upgrade to Delphi 11.3. 4. You now want to build and release version 1.1 from your fixes only 1.x branch, but ideally you want to build with Delphi 11.2. If Delphi 11.3 only contained bug fixes then you might be happy to build 1.1 with it, but 11.3 is a feature release. So for a workflow like the above you actually need to keep build VMs around for all maintained fixes only branches.

I need to do work before I can do that. It's really frustrating that I cannot have 11.2 and 11.3 installed on the same machine.

I'll bet that there is a clean solution to your problem, but not the one you are trying. Instead of asking about pre-processing DEF files, why not ask about the root problem, rather than the solution you imagine using, which you now know is not possible.

Doesn't EXPORTS CCfgClassNew work?

I'd been working with 11.2 to get my app looking good in high DPI settings. This was all fine. Now with 11.3, loads of things look terrible again. One step forward, two steps back. 'Twas ever thus.

No prizes for guessing what happened there. I did a complete uninstall, and then a re-install succeeded.

This aspect of installation isn't much fun

Pretty hard to make such recommendations. Really depends a lot on how your users want to use your software. Are they going to want to have floating licenses? Metred usage? Cloud hosting of license manager? We have a lot of customers that don't have a shared network and collaborate entirely in the cloud with 365 or similar. Solutions to allow such users to share licenses aren't trivial. Of course, you may know that you will never have customers with such needs, or at least not in the short term.

This statement is incorrect unless I am very mistaken. Please show your main form code and the project file.

Not in a def file, perhaps you aren't familiar with def files. They are used to specify exported functions, typically at the link phase in C and C++ tool chains. See: Module-Definition (.Def) Files | Microsoft Learn

No. No language or library support for anything like this.

Yes.

No. When OwnsObjects is true, as it is here, the list is the owner.

Likely because it has been properly designed by skilled practitioners in this field.

Works fine here on the latest Delphi. Are you still using Seattle?

Yeah, defo

I definitely hope that no Delphi code is running by 9999. I'd be amazed if there were any humans left on the planet when that year comes around.