DDevExtensions 2.82 is a rather small update. It fixes the “Switch to the module’s project” incompatibility with XE6 and adds the option to disable the alpha-sort for the IDE’s class completion (Ctrl+Shift+C).

If alpha-sort class completion is disabled and you press Ctrl+Shift+C all methods from the class declaration are appended to the already existing implementation methods in the order that they appear in the class declaration with the exception for constructors and destructors. They are positioned before every other method (class ctor, class dtor, ctor, dtor, methods). This function does not resort your existing implementation methods, nor does it prevent the IDE from sorting the methods that are added to the class declaration because they only have an implementation.

IDE Fix Pack 5.7 increases the max. number of resources per binary from 3626 to 65534 (for the command line compiler you need fastdcc). The installer IDEFixPackReg*.exe now supports the “/EXTRACT” command line switch that extracts the installation files to the sub-folder “Files” instead of installing them. This version also adds some smaller optimization, especially for Delphi 2009 and extends the LineEditorEnd.ttr workaround by not creating the file in the first place.

DDevExtensions download:

DDevExtensions Version 2.82 (2014-08-25)

• Added: Disable Alpha-Sort Class Completion (Default off)
• Fixed: XE6 broke “Switch to module project” dialog

IDE Fix Pack download:

fastdcc download:

IDE Fix Pack changlog

• Added: Fix for “class operator In” class completion
• Added: IDEFixPackReg*.exe supports command line parameter /EXTRACT that extracts the files instead of installing them
• Added: Disable creation of EditorLineEnd.ttr (2009-2010)
• Added: Fix for QC 111917: RLINK32: Too many resources to handle. Instead of 3626 it can now handle 65534 resource items (also in fastdcc for command line compiler)
• Added: TObject.FieldAddress optimization for DFM loading
• Added: String function replacements without STRINGCHECKS (2009-2010)
• Changed: Disabled “.NET Windows\Globalization search I/O optimization” patch for Windows 8 (2009)
• Added: TComponent.Remove optimization (2009)

With the latest Windows updates (KB2982791, KB2970228) Delphi 8-2010 can’t be started twice without a reboot because the IDE wants to create the file %TEMP%\EditorLineEnds.ttr that is now locked by the system.

The IDE extracts a FONT-resource to %TEMP%\EditorLineEnds.ttr and then loads it with AddFontResource(). The IDE’s finalization code unloads the font. But with the newest Windows Updates, Microsoft prevents the RemoveFontResource() function from unlocking the file (for security reasons). If you start a second IDE the resource-extraction fails and throws an exception causing the IDE to terminate.

If you have IDEFixPack newer than 2.7 already installed, you are not affected because IDEFixPack prevents the IDE from calling AddFontResource (this was a patch to work around a performance nightmare with an installed Adobe Type Manager). Thus the file is never locked.

If you are a new user to IDEFixPack, you may need to reboot after installing IDEFixPack if the font file is already locked.

IDEFixPack for 2009 or newer

IDEFixPack for 2006/2007 (if you have Windows 8 you need to use version 4.3 instead of 4.4)

If you have many DFM files and RES files in your project you may run into the rlink32 error “Too many resources to handle”. Every DFM file is one resource and a RES file can contain multiple resources. All together must not exceed 3626 resources.

This limit comes from how rlink32 pre-allocates memory for all resources.  The following pseudo code shows the memory allocator.

function AllocateResourceArray(var AllocatedSize: Word): PResourceArray;
var
  Size: Integer;
begin
  Size := $FF00;
  repeat
    Result := GetMemory(Size);
    if Result <> nil then
    begin
      AllocatedSize := Size;
      Exit;
    end;
    Dec(Size, $400);
  until Size < $400;
  AllocatedSize := 0;
end;

There is an easy fix without much code change:As you can see the max. number of bytes for the whole resource array is limited by $FF00 (65280) bytes. A resource array item’s size is 18 Bytes. That makes 3626 items. If the memory allocator can’t allocate enough memory it tries to allocate again with 1024 bytes less. So the max. number of resources can be lower than 3626. But wait, we have 2014 and not 1992 (rlink32.dll’s copyright message) and RAM is like sand on the beach, at least some developer think that. The 64KB age is long gone, but due to this function rlink32 will fail with “Too many resources to handle” if the 3627’s resource is processed.

Change the var-parameter from “Word” to “LongWord” and set the initial size to $11FFDC (1,179,612 bytes) which makes room for 65534 resource items which should be enough at the moment. Adjust the code that calls into this function (there is only one call). Recompile rlink32.dll.

Unfortunately I can’t recompile rlink32.dll due to the lack of source code, so I need to patch the machine code. And changing the data type from “Word” to “LongWord” isn’t that easy as you have to patch a lot more places that the compiler would just generate for you (fortunately the 32-bit opcodes are usually smaller than the 16-bit opcodes).

This bug fix for the rlink32 error will be in the next version 5.7 of IDE Fix Pack (for the IDE compiler) and fastdcc (for the command line compiler).

IDE Fix Pack version 5.6 adds support for RAD Studio XE6. All patches that are in version 5.5 for XE5 are also in 5.6 for XE6 except the patch for QC 111998 ($TDW macro used in Tools causes crash) that is fixed in XE6.

XE6 introduces a project option to compile projects with the command line compiler instead of the IDE compiler. This can be used to reduces the IDE’s memory consumption during compilation. Because the command line compiler is executed in a different process, all patches that are applied to the IDE compiler don’t work. In order to get IDE Fix Pack’s optimizations into the command line compiler the fastdcc hook DLLs are loaded into the compiler process and you see the “Compiler Speed Pack – Compiler patches applied.” output in the message pane. Only DCC32.EXE, DCC64.EXE and DCCAARM.EXE are supported.

Changelog

• Added: Support for XE6
• Added: CompilerSpeedPack for Android (XE6)
• Added: Apply CompilerSpeedPack to external compiler execution (dcc32, dcc64, dccaarm) (XE6)

IDE Fix Pack Download:

fastdcc Download:

DDevExtensions 2.81 adds support for RAD Studio XE6.

DFMCheck 1.5 supports RAD Studio XE6.

System.ByteString for RAD Studio XE6 gives you the (hidden) native Byte-String types for all mobile platforms back.

Before I can install XE6 I have to uninstall some older versions of RAD Studio because I will run out of disk space on my SSD when I install XE6. The newer the Delphi version is the more disk space it takes, mainly due to the variety of supported platforms (Win32 debug/Win32 release/Win64 debug/…) After installing XE5 I was left with 12 GB free disk space (all the installation image in ProgramData are moved to my HDD) and half a year later I’m down to 6 GB.

I won’t be able to support my IDE plugins for some older RAD Studio versions the moment I uninstall them.

Why not move the older IDEs to another disk and hard link them?
I use the disk space issue as a way out of supporting all those versions with all their compilers dcc32.dll, dcc32.exe, dcc64.dll, dcc64.exe, dccaarm.exe. Do the math. I have to spend too much time doing the research for ever compiler. I have the feeling that the C/C++ compiler that is used to compile the Delphi compilers changes the CPU register allocation with every version, what breaks my “byte sequences” that are used to find the hook addresses. Furthermore I have to test every patch with every version and all compilers before I can release it.

• Supported: RAD Studio 2009 (I use it at work)
• Unsupported: RAD Studio 2010 (extra research costs)
• Supported: RAD Studio XE (I use it for all my personal projects)
• Unsupported: RAD Studio XE2 (only used it for IDEFixPack and DDevEx, obsolete with XE3)
• Unsupported: RAD Studio XE3 (only used it for IDEFixPack and DDevEx, obsolete with XE4)
• Unsupported: RAD Studio XE4 (only used it for IDEFixPack and DDevEx, obsolete with XE5)
• Supported: RAD Studio XE5 (supported until XE7 comes out)
• Supported: RAD Studio XE6 (not yet)

XE5 Update 2 broke the Android System.ByteStrings.o file. So I recompiled it with XE5 Update 2 and now you can use the Byte-Strings (UTF8String, AnsiString, RawByteString, ShortString) also with XE5 Update 2.

The unit System.ByteStrings reintroduces:

• ShortString
• AnsiString
• AnsiChar
• PAnsiChar
• PPAnsiChar
• UTF8String
• PUTF8String
• RawByteString
• PRawByteString

Usage:
Add the System.ByteStrings.dcu’s path to the compiler’s search path and add the unit to your uses clauses.

There is no *.PAS file because the DCU is patched with a hex editor to get access to the hidden types.

IDE Fix Pack 5.4.1 adds support for the just released XE5 Update 2.

If you use the older version 5.4 with XE5 Update 2 you will see one or two error messages (depending on if you have the x64 compiler installed) that tell you that one patch couldn’t be applied to the x86 and x64 compiler. This is caused by a small change in the code generator of the compiler that is used to compile the Delphi compiler. It now generates a “mov cl,[edi+$0c]” instruction where it used to generate “mov dl,[edi+$0c]” since Delphi 2010.

IDE Fix Pack 5.4.1 for XE5 now supports both instructions so that you can use it with XE5 RTM, Update 1 and Update 2. All other IDE Fix Pack editions for 2009-XE4 are still on version 5.4 as the only change happened for XE5.

Download:

fastdcc

The CLANG compiler that is used for BCC64 in XE3, XE4 and XE5 has a “bloated object file” problem if it comes to debug information for deeply nested templates. The generated object file can easily grow to 100 MB with a single line of code.

int main(int argc, char *argv[])
{
    std::map<TEnumA, std::map<TEnumB, std::map<TEnumC, std::map<TEnumD, std::map<TEnumE, std::map<TEnumF, std::map<TEnumG,
      std::map<TEnumH, std::map<TEnumI, std::map<TEnumJ, std::map<TEnumK, std::map<TEnumL, std::map<TEnumM, char* > > > > > > > > > > > > > Dummy;

    Dummy[TEnumA::TEnumAVal1][TEnumB::TEnumBVal1][TEnumC::TEnumCVal1][TEnumD::TEnumDVal1][TEnumE::TEnumEVal1][TEnumF::TEnumFVal1]
      [TEnumG::TEnumGVal1][TEnumH::TEnumHVal1][TEnumI::TEnumIVal1][TEnumJ::TEnumJVal1][TEnumK::TEnumKVal1][TEnumL::TEnumLVal1]
      [TEnumM::TEnumMVal1] = "Booooom!";

    return 0;
}

The problem comes from creating a debug information string for template arguments in the method TemplateSpecializationType::PrintTemplateArgumentList in clang/lib/AST/TypePrinter.cpp. If you have deeply nested templates like the one above, all the code and declarations that std::map brings with it, creates really long debug information strings (600,000 chars and more). And with CLANG’s ability to be helpful in finding template errors, it also records the original template name of a typedef’ed template parameters and creates a debug information string that containing the original template name everywhere where the typedef is used.

The code above creates so many huge debug information strings that the object file becomes over 100 MB large. Depending on the number of such template instantiations in your code, the file can easily become larger than the available RAM. But that isn’t necessary to get the out of memory. The linker (ilink64) will run out of memory even with this “little” 100 MB object file.

The easiest but unpractical solution is to disable debug information.

With the next IDE Fix Pack there is another solution. IDE Fix Pack hooks into the compclang.dll and shortens the strings. If the number of chars exceeds 2048, every further template parameter will be replaced by “…”. That makes those strings not only much smaller but the compiler will also generate the debug information much much faster because there is less recursion and less string concatenation.

I can only guess why the linker runs out of memory with a 100 MB object file. I assume that it does some unfortunate memory allocations for the debug information. But after finding a solution to shrink the debug information in the object file, I didn’t need to look into the linker.