The new IDE Fix Pack 4.6 mainly addresses performance and memory leaks in the compiler and debugger. This version also fixes a race condition from the XMLSerializer cache in 2009-XE that sometimes caused a dead lock during the IDE start.
Version 4.6 supports the just released XE2 Update 3. The reason for the incompatibility is that Embarcadero changed some records in the compiler (what is their right) and all my hard coded offsets didn’t work anymore. Usually my patching code should catch those changes and disable the failing patches. But due to the number of RAD Studio version that I support, I changed many byte sequences, that I use to find the functions in memory, and inserted wild card bytes where memory offsets are, so I can patch all compiler versions with the same byte sequence. Thankfully, Embarcadero was kind enough to add the “incompatibility problem” to the XE2 Update 3 release notes.
Starting with IDE Fix Pack 4.6 for XE2, I added code that checks for the IDE’s version number and it won’t allow you to start the IDE with an IDE Fix Pack version that wasn’t compiled with the same RAD Studio Update. So IDE Fix Pack 4.6 for XE2 can only be used with XE2 Update 3. For all previous or future RAD Studio updates, it will show you a dialog and then terminate the IDE.
Download:
Name | IDE Version | File | Size | Downloads | Added |
---|---|---|---|---|---|
IDE Fix Pack 6.4.2 | 2009 (UP4) | IDEFixPack2009Reg64.2.7z | 242.75 KB | 5717 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | 2010 (UP5) | IDEFixPack2010Reg64.2.7z | 237.09 KB | 6520 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE (UP1) | IDEFixPackXEReg64.2.7z | 221.38 KB | 4048 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE2 (UP4+HF1) | IDEFixPackXE2Reg64.2.7z | 316.78 KB | 4465 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE3 (UP2) | IDEFixPackXE3Reg64.2.7z | 257.4 KB | 3594 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE4 (UP1) | IDEFixPackXE4Reg64.2.7z | 260.1 KB | 3206 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE5 (UP2) | IDEFixPackXE5Reg64.2.7z | 257.7 KB | 3697 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE6 (UP1) | IDEFixPackXE6Reg64.2.7z | 423 KB | 3394 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE7 (UP1) | IDEFixPackXE7Reg64.2.7z | 429.48 KB | 4549 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | XE8 (UP1) | IDEFixPackXE8Reg64.2.7z | 431.7 KB | 3837 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | 10 Seattle (RTM/UP1) | IDEFixPackD10Reg64.2.7z | 428.33 KB | 5328 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | 10.1 Berlin | IDEFixPackD101Reg64.2.7z | 430.65 KB | 5912 times | 2019-03-23 |
IDE Fix Pack 6.4.2 | 10.2 (RTM/UP1/2/3) | IDEFixPackD102Reg64.2.7z | 426.27 KB | 9371 times | 2019-03-23 |
IDE Fix Pack 6.4.4 | 10.3 (RTM/UP1/2/3) | IDEFixPackD103Reg64.4.7z | 444.98 KB | 17760 times | 2019-08-01 |
Changelog from 4.5 to 4.6 (2011-12-15)
- Added: After compile/debug unused compiler memory is released
- Added: LiveBindings slowed down the IDE (XE2) [XE2 Update 3 fixed it differently]
- Added: Compiler Package optimization
- Added: Delphi-Debugger GetFileIndex optimization
- Added: Debugger memory leak fix (XE2)
- Added: Memory leak fix for Debugger’s GetModuleFileNameEx calls (2009-2010)
- Added: Improved the performance when debugging the IDE (2009-2010)
- Improved: C++ Debugger symbol reader performance
- Fixed: XML Serializer cache race condition (2009-XE)
Thanks!
Hi Andy,
works like a charm with Delphi XE 2 / Update 3 – as usual!
Thanks a lot, you’re the (Delphi) man..
Best regards
Dirk
> raise condition
race condition 🙂
fixed 🙂
it is somewhat distrubing that Embarcadero not only remarked that older versions would not work, but that that went so far as to post in the release notes to expect an update from you.
Granted, it is an acknowledgement of the quality and importance of your work, but having crossed that line, it also feels like Embarcadero has given up.
I asked them to add that sentence to their release notes. So don’t blame Embarcadero. I made IDE Fix Pack binary dependent. It is Embarcadero’s right to change their code without asking me. I’m the one who patches the compiler, so I need to stay up to date.
as opposed to them fixing the things you have identified and shown how to fix.
your work is great, but for it to become a cornerstone of a stable, effective product is a little unorthadox.
There is not much that IDE Fix Pack fixes in the XE2 IDE. Almost all bugs are already fixed by Embarcadero. I slowly turn IDE Fix Pack into a second DelphiSpeedUp. The compiler part is already named “Compiler Speed Pack”.
And there is a huge difference between fixing a bug and improving the performance from a vendor point of view. The former is a blocker, critical, major, … bug. The later is a nice to have feature, that only bubbles up the ladder if the (larger) customers specifically “ask” for it.
but there certainly are a lot of bugs in secondary Pascal parser (the one used in Code Insight, Structure View and such), that are not considered anywhere seriously and remain open for years.
Even if structure panel gets completely unusable, it is still not bug enough 🙁
Andy,
this hangs you mention is related to http://qc.embarcadero.com/wc/qcmain.aspx?d=90864?
the “?” are not part of the link… o.o”
http://qc.embarcadero.com/wc/qcmain.aspx?d=90864
No. It is related to: “The IDE freezes during the splash screen”.
My recommendation is and will always be: Avoid the background compiler like the plague.
You mean Tools -> Options -> Environment Options -> Background Compilation -> Disabled?
Mine is always that. I’ve recently saw that “hang on open project” issue. Not sure the hotfix solved that problem. So, when you said fixed, I was curious how you did that.
You know? I really appreciate your efforts. Thanks.
I fixed my own bug that caused the IDE to not start anymore because I hooked into the WaitForSingleObject function with the assumption that only one thread is active during the IDE start. What I didn’t thought of was that there are “applications” that install global windows hooks like TortoiseSVN, Virus scanners, … that start their own threads and when they call WaitForSingleObject while I wait for one specific call, a deadlock occurred.
But that all has nothing to do with the Background Compiler that should have never been implemented the way it is. A second process would have been much better and more stable for the IDE. Putting a thread into an application that wasn’t designed to be multi-threaded from the beginning can only result in problems. Best example: Delphi 2005 where the Error Insight parser was introduced. One deadlock after another.
Pingback: Applying XE2 Update 3: uninstall IDE Fix Pack first, then apply, then install updated IDE Fix Pack. Also update EurekaLog. « The Wiert Corner – irregular stream of Wiert stuff