RAD Studio 13 is available

[ToddFrankson 15]

9 hours ago, Uwe Raabe said:

Unfortunately the migration tool just copies the Known Packages list from 12.3 to 13 per default. This can only work when packages are binary compatible like from 12.2 to 12.3, but as packages from 12.3 cannot work in 13 the failing is expected.

 

There are means to use the migration tool in a way that avoids this, but it requires some manual steps. Known Packages and Experts cannot be migrated between major versions, so you always need to compile (or get the right versions from the vendor) and install these packages and dlls with D13 anyway. 

 

I would love to see the migration tool getting some love for its details and default behavior. As it often is used by less experienced (or lazy) users, a stable and correct click-and-run experience should be mandatory.

 

I never used it before.  The first time trying it.  Sad it isn't smarter or easier to use.

[Anders Melander 2135]

12 hours ago, Uwe Raabe said:

Unfortunately the migration tool just copies the Known Packages list from 12.3 to 13 per default. This can only work when packages are binary compatible like from 12.2 to 12.3, but as packages from 12.3 cannot work in 13 the failing is expected.

That's not entirely true. If you do an Upgrade migration then it copies the package settings. If you do a Version migration then it doesn't.

The UI could have made the distinction clearer...

 

[Edit] Sorry, I see you already made this point. For some reason you later posts didn't show when I wrote the above. The forum has been extremely slow for me the last few days. It's almost unusable. We're probably getting DDOSed harvested by some engine.

Edited September 19 by Anders Melander

[A.M. Hoornweg 161]

I think I've found a bug:

We have a Finalbuilder 8 compilation script that fails with Delphi 13 (not 12) because the resource compiler cgrc.exe throws an error message "unable to execute rc.exe". 

 

This file is indeed missing in the directory  "...Embarcadero\Studio\37.0\bin".   After manually copying this file from the Windows SDK, the Finalbuilder script works.  

[Lars Fosdal 1958]

@A.M. Hoornweg Did you upgrade FB to latest?

[A.M. Hoornweg 161]

9 minutes ago, Lars Fosdal said:

@A.M. Hoornweg Did you upgrade FB to latest?

Yes! (prior versions don't support Delphi 13).

 

The error is output by Embarcadero's cgrc.exe, not by FB.

Edited September 25 by A.M. Hoornweg

[Remy Lebeau 1676]

7 hours ago, A.M. Hoornweg said:

I think I've found a bug:

We have a Finalbuilder 8 compilation script that fails with Delphi 13 (not 12) because the resource compiler cgrc.exe throws an error message "unable to execute rc.exe". 

 

This file is indeed missing in the directory  "...Embarcadero\Studio\37.0\bin".   After manually copying this file from the Windows SDK, the Finalbuilder script works.  

It's not a bug.

 

Starting with 13, the Windows SDK is no longer bundled with the IDE, it needs to be installed separately, and rc.exe is part of the SDK:

https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New#Installation_Process_Updates

 

A new open-source resource compiler named resinator has been added in 13 and is now the default:

https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New#Resource_Compiler

 

So, if you want to continue using rc.exe, you need to install the Windows SDK (or copy it from an earlier installation, as you found).

 

At the project level, you can configure which resource compiler to use (brcc32, resinator, or rc):

https://docwiki.embarcadero.com/RADStudio/Florence/en/Resource_Compiler_Options

Edited September 25 by Remy Lebeau

[A.M. Hoornweg 161]

55 minutes ago, Remy Lebeau said:

It's not a bug.

 

Starting with 13, the Windows SDK is no longer bundled with the IDE, it needs to be installed separately, and rc.exe is part of the SDK:

https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New#Installation_Process_Updates

 

A new open-source resource compiler named resinator has been added in 13 and is now the default:

https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New#Resource_Compiler

 

So, if you want to continue using rc.exe, you need to install the Windows SDK (or copy it from an earlier installation, as you found).

 

At the project level, you can configure which resource compiler to use (brcc32, resinator, or rc):

https://docwiki.embarcadero.com/RADStudio/Florence/en/Resource_Compiler_Options

Hi Remy,

 

the current SDK is installed, or course, and we even manually appended the directory where rc.exe is located to the system path. If I type "rc.exe" in the command line, it is found and executes without problems.

 

The problem is that a Finalbuilder script of one of my coworkers calls Embarcadero's cgrc.exe resource compiler, I'm not certain why he uses that.  That executable seems to depend on rc.exe being in the same directory - it's not sufficient if rc.exe can be found through the PATH.

 

 

 

 

 

 

[Remy Lebeau 1676]

2 hours ago, A.M. Hoornweg said:

The problem is that a Finalbuilder script of one of my coworkers calls Embarcadero's cgrc.exe resource compiler, I'm not certain why he uses that.  That executable seems to depend on rc.exe being in the same directory - it's not sufficient if rc.exe can be found through the PATH.

cgrc.exe is for the IDE's internal use when invoking rc.exe with brcc32-style parameters.  If a script wants to invoke rc.exe then it should probably just invoke it directly.

[Uwe Raabe 2230]

5 hours ago, A.M. Hoornweg said:

I'm not certain why he uses that.

Most likely because it has been that way forever.

[A.M. Hoornweg 161]

On 9/26/2025 at 12:57 AM, Uwe Raabe said:

Most likely because it has been that way forever.

He just told me it was because brcc32 doesn't support 256x256 png-format icons and because cgrc was simply the next option that Finalbuilder offered in the action "Embarcadero Resource Compiler".  

 

"Resinator" isn't an option yet in Finalbuilder, I hope @Vincent Parrett reads this post...

 

 

it's one of the three pre-defined

 

 

 

 

[Jonah Jeleniewski 21]

On 9/17/2025 at 4:09 PM, Attila Kovacs said:

Does any of them keep the bookmarks?

It used to be a big disadvantage that the bookmarks disappeared. (Many many years ago)

Belated reply, but pasfmt integrates with the IDE and tracks/retains bookmarks across formats.

[dummzeuch 1741]

On 9/17/2025 at 10:26 AM, Sherlock said:

That seems to be a hard requirement to fulfill, seeing as bookmarks (IIRC) are tied to line numbers and line numbers may change after formatting.

Since this topic just came up again: Actually, bookmarks are tied to a specific character position, so not just the line but also the column. For Breakpoints it's only the line number.

GExperts tries to preserve both by keeping track of the positions of the tokens.

[Uwe Raabe 2230]

The problem with bookmarks and breakpoints is that they are bound either to the current project group or the current project (with a fake group), whatever is opened. Any attempt to keep those during formatting will most likely still damage any of the others.

 

F.i.: Assume unit X is used in several projects. Formatting unit X while project A is open may keep the breakpoints, but the breakpoints saved in project B may not match anymore when opened.

[Jonah Jeleniewski 21]

12 hours ago, Uwe Raabe said:

The problem with bookmarks and breakpoints is that they are bound either to the current project group or the current project (with a fake group), whatever is opened. Any attempt to keep those during formatting will most likely still damage any of the others.

 

F.i.: Assume unit X is used in several projects. Formatting unit X while project A is open may keep the breakpoints, but the breakpoints saved in project B may not match anymore when opened.

That's true. Of course, this isn't a unique problem to source code formatting tools - more like making any change to a shared unit will affect breakpoints/bookmarks in projects that aren't in the current project group.