GitHub – KirillOsenkov/LargeAddressAware: A build tools package that adds support for making 32-bit exes LARGEADDRESSAWARE (and some words on a 64-bit Delphi product)
Posted by jpluimers on 2024/06/26
[Wayback/Archive] GitHub – KirillOsenkov/LargeAddressAware: A build tools package that adds support for making 32-bit exes LARGEADDRESSAWARE
Hopefully this can be applied to Delphi projects as well. If not then in Delphi you can manually call this in an post-build task.
Via [Wayback/Archive] Meik Tranel on X: “Please for the love of all that is holy. Do not build #dotnet tools to serve a non interactive task that is supposed to be run during a build – use an #MSBuild task package. Also #JS/#NPM devs should not be allowed to write tooling. Thanks for coming to my ted talk…”.
The Delphi bit inspired a few months ago by: [Wayback/Archive] Andreas on X: “Will there ever be a 64bit Delphi IDE or at least a LargeAddressAware version. Our Projekt crashes the IDE between 14-18 compilations because it runs out of memory. Maybe I have to patch the IDE myself by moving all .NET and Compiler memory allocations above the 2 GB address.”
That got retweeted last weekend with the news that there will be a 64-bit Delphi compiler followed by a 64-bit Delphi IDE. Finally….
[Wayback/Archive] MarcoCantu on X: “There will be a Delphi compiler built as a 64-bit binary first, and a 64-bit IDE later. Working on it”
My guess is that they will follow similar steps back from around when the .NET compiler and IDE for Delphi got created and released (versions 7 through 2007), hopefully without the stability and feature removal issues (with Ian Barker now as Embarcadero Developer Advocate – basically head of what was previously called Developer Relations – I have gained confidence in this):
- Delphi 7 introduced the [Wayback/Archive] Delphi for .NET compiler preview (dead link)
- [Wayback/Archive] Using the Delphi for .NET Preview compiler in the Delphi 7 IDE (dead link)
- Delphi 8 which was a .NET-only release
- Delphi 2005 which removed CLX support (Kylix) for new projects, but added back the 32-bit Windows support, but was almost as buggy as Delphi 8
- Delphi 2006 which was basically the product that Delphi 2005 should have been
- Delphi 2007 which added .NET 2.0 support and support for msbuild, but also dropped the C#-Builder portion and the .NET WinForms designer.
- Delphi 2009 which added Unicode support and support for generics plus anonymous methods, but removed the Delphi .NET compiler replacing it with the (not fully source code compatible) Delphi Prism compiler
This will be a major undertaking, especially as it looks like the IDE will be 64-bit, which likely implies a 64-bit debugger, 64-bit form designer, 64-bit components, 64-bit experts, etc.
Since 64-bit VCL has been there for a while, many 64-bit components are already there, but their current designers are all 32-bit (because the Delphi IDE is 32-bit) which means they need to be tested and adapted for a 64-bit IDE.
In that sense introducing a 64-bit Delphi IDE is similar to two other past big product architecture steps:
- Kylix, which had CLX: component library cross platform, a VCL for both Linux and Windows (added in Delphi 6, but dropped in part with Delphi 2005 and in full with Delphi 2006)
- Delphi 2 replaced the 16-bit product with a 32-bit product (compiler, IDE including debugger, form designer components, experts), but for backward compatibility included the 16-bit Delphi 1 product
To get a feel on how closely back then the release dates were together, just look at [Wayback/Archive] Delphi Release Dates | Delphi Programming | Fandom (which misses the 2003 release of C# Builder, though that technically is not a Delphi product, but a very important step into getting Delphi 8 released).
The late Danny Thorpe had a huge influence in getting traction for both the Kylix and Delphi .NET products, but due to the large organisation it took too long for the execution to hit the sweet spot of being viable. Kylix got released right before the dot-com bomb and Delphi .NET could not keep up with Microsoft.
Now that Delphi is in its established niche, I think the 64-bit version will be much more viable.
Note that a lot of information on the Delphi .NET era has vanished. This is a pity as it introduced major language features (like class helpers). Luckily this detailed blog posts are still there:
Back to the Tweets by Meik Tranel, here are some more:
- a
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 If what you’re trying to offer is something that can fits perfectly within the build pipeline of a csproj, look at something like … or … – these can be neatly attached to existing extension points of the pipeline.”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 For the counter example: lets look at … which is a dotnet tool that runs a slew of SCSS related tasks. Inputs are defined and outputs are supposed to end up being picked up by the sdk at some point.”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 But the author decided that somehow a console program is the right tool for the job. its not. You lose the ability to track in’s and out’s of a task, with that neat logging and viz using @KirillOsenkov’s structured log viewer. You also have to integrate dotnet tool restore…”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 @KirillOsenkov you lose guaranteed process safety because dotnet tool restore is not atomic therefore multiple projects built in parallel all introducing restore steps during project builds start screwing eachother over on file handle ownership and sharing.”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 @KirillOsenkov same goes for “npm install -g” btw – just that the node ecosystem never defined a skeleton – everyone just wings and reinvents the wheel with each major release. thats why every framework needs their own revolutionary cli, templating engine and dank log theme.”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 @KirillOsenkov MSBuild solved that whole fiasco by providing anchor points everyone can attach to. And they dont break those all that much. CoreCompile, ResolveReferences, Restore, TargetsTriggeredByCompilation, PrepareForRun – those never changed really.”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 @KirillOsenkov The well defined extension points, SDKs, PackageReference and ProjectReference protocol is why i think MSBuild is right up there with stuff like git – no more and no less than some of the greatest pieces of software on this planet.”
- [Wayback/Archive] 😈 Evil Mike (on indefinite hiatus) on X: “@MeikTranel @KirillOsenkov Although I agree in a lot of points, I am not sure if you are entirely objective on the matter of dotnet tool vs msproj build step. I mean Microsoft itself started the whole dotnet tool as build step movement, probably for good reasons. But I get what you are saying. Thank you!”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 @KirillOsenkov dotnet tools have their perfect niche – ef core tools for example. You dont create migrations during CI. You create them locally. You have no interest to watch a workspace for changes when its checked out in a github pipeline.”
- [Wayback/Archive] Meik Tranel on X: “@Hummigbird1 @KirillOsenkov NGBV is a fantastic example – (a tool nearly all MS/dotnet repos use themselves btw) – … the tools purpose is to manage one off tasks, a user interface for branching strategies and modifying the version.json. Their MSBuild package then integrates back”
[Wayback/Archive] Nerdbank.GitVersioning/doc/nbgv-cli.md at main · dotnet/Nerdbank.GitVersioning
--jeroen
PS: the dead links are because Embarcadero isn’t particularly well at maintaining infrastructure or information, so they tend to choose ditching information instead of preserving it fur future users.
The Wiert Corner - irregular stream of stuff 
Leave a comment