Delphi 12.3 Update

-

The Delphi 12.3 update has just been released.


The most exciting part of this release is the long-awaited 64-bit IDE. Now, this is only an Initial Release of the IDE, and it is not yet a full replacement for the 32-bit IDE and its functionality.

The main advantage of the 64-bit IDE is that the available memory is no longer constrained by the 32-bit address space, and the upper limit is now the available system memory. The more you have, the more you can use. This is a great news for all developers with large projects, where the 32-bit IDE would easily hit the memory wall.

To start with, the 64-bit IDE only supports the 64-bit Windows platform. The primary purpose of such a release with only partial functionality is to allow all component developers to update their design-time packages, and prepare them to support the 64-bit IDE. And to do that, you only need the 64-bit Windows platform anyway. For all other platforms, there is no immediate advantage of using a 64-bit IDE.

As we all know, the bitness of the design-time packages loaded in the IDE needs to match the bitness of the IDE, and until now, those packages could only have been built for the 32-bit Windows platform. This was also a major pain point when using the 32-bit IDE for design-time packages that depended on other DLLs and drivers. As the world moved to 64-bit, more and more of those were beginning to release exclusively 64-bit versions.

Releasing the early preview of the 64-bit IDE will give everyone plenty of time to start the 64-bit migration. How hard such a migration will be for each individual package will largely depend on the used code.

For me, moving all design-time packages to 64-bit was merely a matter of recompiling them in the new IDE. It took only a few minutes. However, my packages are small and simple, and your mileage may vary.

Also coming with the new IDE is a new LLDB-based debugger. This part is a mixed bag. On the one side, LLDB allows better integration with other tools; on the other side, in some ways, the current debugger release and LLDB itself are no match for some features of the old debugger, which had been carefully crafted around the Delphi language.

Not to mention that LLDB is not exactly known for its stellar speed. Apple contributed some speed-related improvements to the LLDB, but they were only recently merged back to the LLDB, and this release of the Delphi IDE is not yet using the LLVM version which incorporates those improvements.

Still, this is a great initial step towards a future, fully functional, 64-bit IDE.

You can find more information about what is new in this update at https://docwiki.embarcadero.com/RADStudio/Athens/en/12_Athens_-_Release_3

Comments

Post a Comment

Popular posts from this blog

Assigning result to a function from asynchronous code

-
One of the more common problems that comes up in multi-threading, especially when refactoring existing code, is assigning a result obtained from asynchronous code. In other words, how do you write a function that will return some value, and calculate that value in a background thread? Basically, converting the following code: function GetData(...): string; var Data: string; begin Data := LongTask(...); // assign result of a long-running task to a function Result := Data; end; To this one: function GetData(...): string; var Data: string; begin TThread.CreateAnonymousThread( procedure begin Data := LongTask(...); end).Start; // assign result of a long-running task to a function Result := Data; end; Now, the above code will compile, but it will not achieve the desired functionality. Even if we ignore its thread safety issues (the background thread writes to the Data variable and that can interfere with assigning it to the function result), the funct...
Read more

Celebrating 30 Years of Delphi With a New Book: Delphi Quality-Driven Development

-
Image
This year, on February 14th, Delphi celebrates its 30th birthday. Over the past three decades, Delphi has proven to be a robust and versatile development environment, empowering developers to build high-performance applications with ease across multiple platforms: Windows, Linux, Android, iOS, and macOS.  As we commemorate this milestone, I am also introducing a new book to help guide you into Delphi's fourth decade: Delphi Quality-Driven Development. Useful to lone developers and vast teams alike, this book aims to demonstrate a variety of essential practices and techniques for making high-quality, testable code. There is a 25% sale going on until the end of February for the Delphi Quality-Driven Development ebook, and there you can also get an additional discount on other books if you add them to your order. To all my fellow Delphi developers: May your code compile quickly, your memory be manageable, and your code testable.   Delphi Quality-Driven Development Book A practica...
Read more

Hello Old New Leaky Friend

-
Image
Developers that extensively use interfaces in Delphi probably know about a long-standing issue with the compiler, where interface parameters declared as const or [ref] will cause a memory leak if a reference-counted object instance is constructed directly at the call site. Illustration: Sandra Prasnikar        Specifically, the following code would create a leak: procedure LeakTest(const Intf: IInterface); begin end; procedure Run; begin LeakTest(TInterfacedObject.Create); end; begin ReportMemoryLeaksOnShutdown := True; Run; end. The problem arises because the compiler does not create a hidden interface reference that would properly initialize the reference counting mechanism and keep the object instance alive during the call. In other words, such an object would never be assigned to a strong interface reference. Because const and [ref] parameters don't trigger reference counting, if there is no other code within the called routine, the obj...
Read more