jbg

TEncoding has a GetBytes() method that accepts PWideChar and PByte. Unfortunately it is "strict protected". So you would have to derive a class from TUTF8Encoding and then use that. Alternatively you can use the LocaleCharsFromUnicode system function. ByteCount := TEncoding.UTF8.GetByteCount(S); Buf := GlobalAllocPtr(0, ByteCount); if ByteCount > 0 then LocaleCharsFromUnicode(CP_UTF8, 0, PChar(S), Length(S), MarshaledAString(Buf), ByteCount, nil, nil); GlobalFreePtr(Buf); Example for a derived TUTF8Encoding class: type TUTF8EncodingEx = class(TUTF8Encoding) public // make the PWideChar/PByte methods public function GetByteCount(Chars: PWideChar; CharCount: Integer): Integer; override; function GetBytes(Chars: PWideChar; CharCount: Integer; Bytes: PByte; ByteCount: Integer): Integer; override; function GetCharCount(Bytes: PByte; ByteCount: Integer): Integer; override; function GetChars(Bytes: PByte; ByteCount: Integer; Chars: PWideChar; CharCount: Integer): Integer; override; end; { TUTF8EncodingEx } function TUTF8EncodingEx.GetByteCount(Chars: PWideChar; CharCount: Integer): Integer; begin Result := inherited GetByteCount(Chars, CharCount); end; function TUTF8EncodingEx.GetBytes(Chars: PWideChar; CharCount: Integer; Bytes: PByte; ByteCount: Integer): Integer; begin Result := inherited GetBytes(Chars, CharCount, Bytes, ByteCount); end; function TUTF8EncodingEx.GetCharCount(Bytes: PByte; ByteCount: Integer): Integer; begin Result := inherited GetCharCount(Bytes, ByteCount); end; function TUTF8EncodingEx.GetChars(Bytes: PByte; ByteCount: Integer; Chars: PWideChar; CharCount: Integer): Integer; begin Result := inherited GetChars(Bytes, ByteCount, Chars, CharCount); end; begin ByteCount := TEncoding.UTF8.GetByteCount(S); Buf := GlobalAllocPtr(0, ByteCount); if ByteCount > 0 then TUTF8EncodingEx(TEncoding.UTF8).GetBytes(PChar(S), Length(S), Buf, ByteCount); GlobalFreePtr(Buf); end;

You can use the IDE's "process" for the JCL and JVCL but then you have to Build 4 JCL runtime packages and add their source path, library path and resource path (*.obj) to the IDE's settings Repeat step 1. for Win64 Build and install up to 10 JCL Designtime package (the IDE plugins/experts) Build 28 JVCL runtime package and add their source path, library path and resource path (*.obj) to the IDE's settings Repeat step 4. for Win64 Build and install 28 designtime package Repeat all steps for each installed Delphi version and skip the Win64 step if a Delphi version doesn't support it. And that is for one person. If you are in a team and have only one Delphi version installed then the multiplier is the size of your team. UPDATE: And not to forget. You need to compile the packages in the correct order because they depend on each other.

I wouldn't say "many". I would say "a hand full". But marketing is something else. None of the additional features was added. Actually only the patches that give the most performance boosts in usual cases were applied. (But reading the IDEFixPack source code isn't easy as it is a lot of assembler code)

IDEFixPack adds a command line option "-x--compileonly" to the compiler. It skips the linker phase, so no EXE, BPL, DLL, MAP and TDS files are created. But IDEFixPack doesn't exist for Delphi 10.4. So this is no option if you are using the newest Delphi version.

You set the ColorMenu.Style to msOwnerDraw but then you don't implement the OnDrawItem and OnMeasureItem. So your menu items have a width of 0px and a height of 16px. And nothing is painted anyway because OnDrawItem is not assign. The "example form" creates its own style painter TJvXPColorMenuItemPainter and assigns it to ColorMenu.ItemPainter. So this is not a bug but a handling error. procedure TEditorMainForm.FormCreate(Sender: TObject); ... begin ... ColorMenu.ItemPainter := TJvXPColorMenuItemPainter.Create(Self); BackgroundMenu.ItemPainter := TJvXPColorMenuItemPainter.Create(Self);

They ship jdbg files with the BPLs and those are created with the JCL from the map files. So you can read them instead of the map file with the help of the JclDebug.pas (that also has a map file parser and a TD32 debug information parser). There are only two problems with that approach: The JclDebug API only has an "Address to ProcName/LineNum" function but doesn't give you access to the actual ProcNames and Lines lists. But you can change the code and access the private fields (TJclBinDebugScanner). The jdbg files for some files are from the debug build and don't match the actual release code (but that got a lot better in recent releases) or they are from a broken Borland C++ compiler that generates map files with just wrong information (e.g. Delphi compilers).

Does it use a ring buffer (like IDE Fix Pack to make the compile dialog not spend the time on loading the same strings) or did they cache everything? (I don't have access to the new RTL's source code)

I can do that. But I can't build releases for Delphi 10.4.

For all who want to try to get the DDevExtensions Delphi IDE plugin to work with Delphi 10.4 can now clone the DDevExtensions git repository. It contains the project files for Delphi 10.2 and 10.3. I'm not able to help with any Delphi 10.4 issues, so you are on your own. GitHub repository: https://github.com/ahausladen/DDevExtensions

The UnitFindByAlias name is misleading. It doesn't have anything to do with Unit-Aliases. I took the name from the compiler's jdbg file. A much more describing name would be FindUnitByUnitName, because that is what the function actually does.

TBytes suffers from being a dynamic array. If you set its length it will initialize the allocated memory with zeros. So if you allocate a TBytes array and then write data into it (from a file, other memory, socket) you don't need the zero-initialization because you overwrite them anyway. Unfortunately there is no "SetLengthUninitialized" function for TBytes that would get rid of the unnecessary ZeroMemory/FillChar call. I wrote my own function and patched all the TEncoding methods and use it in places were performance matter. I just saw that that was already mentioned in this thread.

Maybe a problem with the Virus-Scanner?

The WebInstaller detection in IdeFixPack looks at a specific environment variable but that variable is also set of you start the IDE with Administrator rights or if some other program added the environment variable. (I don't remember what env-var it is and I don't the the source code at hand where I am right now) The WebInstaller detection code was removed in the last development snapshot: https://idefixpack.de/fixpack/dev But be aware that the development snapshot may crash the IDE more often as it is not tested.

I have uploaded a new development snapshot for the (upcoming) IDE Fix Pack 6.5 IDE Fix Pack Snapshot Download What's new: Added: (IDE) Fix for RSP-23006: Edit controls in the ObjectInspector aren't clipped by the scrollbar anymore (10.3+) Added: (IDE) The compile progress dialog is updated only every 80 ms now. And if a remote desktop session is detected it is only updated every 250 ms. The IDE compiler runs in the main thread, so every GUI update affects the compilation time. Added: -x--jdbg compiler option extension that creates and attaches a jdbg-file. You don't need a detailed map file (-GD) anymore to create or attach a jdbg-file for the binary file. Attaching the jdbg PE section is done after the linker closed the binary file. -x--jdbg and -x--jdbg=1 create a jdbg-file -x--jdbg=2 attaches the jdbg data to the executable/dll/bpl. Question: "Why is the jdbg file smaller than my old file?" - Answer: "The old file was created with an older version of JclDebug.pas." Added: -x--unitstats compiler option extension outputs unit filenames for units with "unitname in 'filename'" entries. Added: -x-fvs compiler option extension also generates faster interface call stubs for virtual methods that are final or in a sealed class. Added: Package compilation is a lot faster in the linker and cleanup phase. Added: Faster ObjectTextToBinary (DFM) implementation by removing unnecessary string comparisons. This improves the linker's performance when it converts DFMs to resources. Added: Faster map file creation by using a much faster Sort-By-Address implementation and a faster \n to \r\n converter. Added: Faster unitname to unit filename resolving (unitname in 'filename') The compiler used a Byte as hash-value and a single linked list. The code is now replaced by a hash-map with a 32 bit hash-value. Added: Faster compiler inline handling for projects with lots of units. Added: The command line compiler uses a double linked unit list to remove and reorder items faster. The IDE compiler still uses the original single linked list because some other code in the IDE does something with it and I couldn't make it not crash. Added: LoadString cache for compiler error/warning/hint messages. The compiler loads the warning/hint string and then decides not to show it. The cache prevents the compiler from calling LoadString too often. Added: Some PAnsiChar/PWideChar RTL optimizations for the IDE and IDE Fix Pack. Fixed: Compiler option extensions didn't work in dcc*.cfg and project.cfg files. Now you can specify -x-* options also in *.cfg files. Fixed: Don't crash if a 3rdParty tool destroys the Castalia Clipboard Form. Fixed: -x-cgo compiler option extension crashed the 10.3 compiler. Removed: The "Exception catcher" patch for ErrorInsight is no more. It didn't have any functionality.

At least it is not as performance damaging as preconditions. I remember the Indy project changed all the "if condition then raise" to something like "EIdException.RaiseIf(condition, ExceptionString-Concatenation)" in 2003/2004 and changed all that back because of the performance hit. And even in Java with a JIT-Compiler you shouldn't use preconditions if you don't know the effect it has: Somebody changed all the exception handling in a Base64 decoder to preconditions and the result was that converting a 500 MB file took hours instead of milliseconds. The garbage collector had to clean up all the strings that were created for every byte that was read and there were a lot of preconditions in the inner most loop.