Leaderboard

There's a potential show-stopper for non-Windows platforms https://www.ideasawakened.com/post/rad-studio-10-4-2-is-great-but-here-are-some-notes

Hello all, in my quest to port a very large project -containing dozens of COM DLL's- from Delphi XE to Sydney, the main obstacle for me was the exploding executable size. Each and every DLL in my project group had grown between 1-4 megabytes and that really added up painfully. Most of that growth, of course, is due to the new extended RTTI (which I do not use). The project was already huge before, and a doubling or tripling in size would cause deployment problems (the software is used on oil wells on remote locations and bandwidth is often costly and slow). Trying to strip off some MB's wherever I could, I started studying the MAP files to make sure no unnecessary stuff was linked in. I noticed that all of my non-visual COM DLL's nevertheless pull in huge chunks of the visual VCL, including units VCL.Forms, VCL.Themes, VCL.Imagelist etc. I am absolutely sure that I don't use these routines anywhere and still they make up over 60% of the executable's code! The underlying cause is that all of the xxxx_TLB.PAS files, which the IDE auto-generates, use a unit called OleServer which has an initialization section. No code in the unit itself is called, but the initialization section manages to pull in most of the VCL for whatever reason. As a test, I made a dummy unit "oleserver.pas" and referenced it as the first file in my COM DLL applications. The project compiled fine, and this change alone instantly reduced executable size with a whopping 1 MB. And the best thing, the project still worked as expected. So it seems to me that this whole OleServer unit is an unnecessary thing in my projects. Another thing. When I link my projects against a "stripped" version of the RTL/VCL (recompiled without extended RTTI), the size difference becomes astronomic. My DLL's have now typically lost 80% of their size, going from 2MB+ to only 400kb. With these executable size reductions I am finally able to port this project to Delphi Sydney. I am in the process of writing a tool to automate the "rtti stripping" of the RTL/VCL which I plan to release as open source. For example, projects like "inno setup" might benefit from it.

My preference: - Place on a form only visual and related components (dialogs, etc). Place Data access components in Data module. Other ones are created dynamically - Use .Create(Form) when component's lifecycle is the same as owner form's. This way the form cares of destroying it - Use .Create(nil) and destroy manually otherwise

If you are not dropping components on the form, then it is better that you pass nil as owner. That way you can use those components in background threads (please note that not all components are thread safe and can be used in the background, but in this case we are talking about Indy). Which is generally preferable when you are doing any kind of network operations. Having multiple try...finally blocks kills readability, so I prefer using only one. You need initialize references to nil, to avoid issues if construction fails somewhere in the middle and finally might call uninitialized pointer. IdSMTP1 := nil; IdMessage1 := nil; IdSSLIOHandlerSocketOpenSSL1 := TIdSSLIOHandlerSocketOpenSSL.Create(nil); try IdSMTP1 := TIdSMTP.Create(nil); IdMessage1 := TIdMessage.Create(nil); ... finally IdSSLIOHandlerSocketOpenSSL1.Free; IdSMTP1.Free; IdMessage1.Free; end;

I did a clean install of Delphi 10.4.2. One of the first steps is to compile and install GExperts. SVN revision 3449 compiled fine, but when running the "Register-GExperts-XX104.cmd" it fails with "Runtime error 217 at 50CDB390", followed by "Problem beim Starten von .\GExpertsRS104.dll. Eine DLL-Initialisierungsroutine ist fehlgeschlagen." To trace the error I compiled GExperts in Debug mode, using Debug-DCUs. Then I used Run->Parameters to set "C:\Windows\System32\rundll32.exe" as "Host", and the full path to the compiled GExpertsRS104.dll and ",InstallGExperts" as parameter: Host application: C:\Windows\System32\rundll32.exe Parameters: C:\Full\Path\To\GExpertsRS104.dll,InstallGExperts Now I could debug the installation from within the Delphi IDE. The startup-code InitUnits (in System.pas) initializes all units and calls class constructors; and in Vcl.WinXCtrls.pas it calls a class constructor TSearchBox.Create. This code creates an internal TImageCollection and adds two default images, which finally leads to TWICImage.Create in Vcl.Graphics.pas (Line 10624 ff). The call to CoCreateInstance(CLSID_WICImagingFactory, ...) fails with error code $800401F0 = CO_E_NOTINITIALIZED = 'CoInitialize has not been called' and an exception is raised with message 'Cannot create instance of class CLSID_WICImagingFactory'. To solve this problem, I need to insert CoInitialize(nil) somewhere, and because I won't change VCL and RTL units I had to find another place. Finally I found that the initialization block in GX_GenericUtils.pas is called some steps before the exception is raised, and already uses unit ActiveX, so I placed a CoInitialize(nil) in GX_GenericUtils.pas initialization block. initialization CoInitialize(nil); // this line added Initialize; ... And the error is gone! Finally I could install GExperts into Delphi 10.4.2 😉 [Yes, I know how to use RegEdit]. @dummzeuch : Maybe there is a better place to insert that missing CoInitialize(nil). Also I don't know if that call has side effects on older Delphi versions and should be surrounded by some IFDEFs. Since it is only one line inserted, I did not create a patch. I'm going to report this new VCL bug to quality portal. Thanks for reading, Achim

I can confirm all above issues. The first one is especially annoing thing for me. And the third also.

You are freeing twice the form: Once from the OnClose because you use caFree caFree, and once when you call Free in the finally block. The second call will crash.

Aren't you freeing the form twice? caFree calls Release, Release posts a CM_Release message and that calls Free..

Yes, you should be able to simply configure the project's search/library paths to point at the Indy 10 source folders rather than the Indy 9 source folders.

All, Found it! It was caused by the Beta version of LMDs 2021 Tools. Eugene is now aware of it and has pointed to the 'switch' to turn it off, it will be taken care of in the release version of LMD Tools 2021. Thanks to all for your input, Ian

Considering the absence of answer to the above as a sign of acceptance, I reported this issue to support@mmx-delphi.de

Making a report is indeed very useful BUT you have to find a reproducible way to make this behavior appear or the report will be closed with "cannot reproduce" reason. Just to test, could you set the 4K monitor to 100% to see if the bad behavior persists? If it persists, could you change the video card resolution to full-HD (1920x1080) and 100% to see if the bad behavior persists?

This post covers manifest files with delphi. https://www.finalbuilder.com/resources/blogs/windows-manifest-files

Goto https://my.embarcadero.com/ and logon and then click on the Download icon in the left panel to get a list of files that you can download.

Still testing, but so far it behaves very well. Feels all in all quite fast and responsive, much improved to my Rx1041. If it compiles now all my projects without big issues (and it looks like that), I would say its close to very satisfying

I used the online installer. AV program is not a problem. I have my installation now running - but Embarcadero should improve the installation process. This error has been known for some time, but so far it is unclear what the trigger is. See RSP-29385. I think this is very frustrating for new users in particular.

Come on, don't be so negative.. it only took from D2006 till now to get here with ErrorInsight..

Apple does not value backward compatibility as much as Microsoft. They make breaking changes a lot, either in OS or their toolchain and that causes various issues. Some issues break application building process, some break applications.

You need 10.4.1 + Patch https://blogs.embarcadero.com/apple-platforms-patch-for-rad-studio-10-4-1/ or the newest 10.4.2

Why not a simple update process instead of every time a full uninstall and install ?

I am also glad we could find a solution - fyi the actual fix was done a bit different as suggested in the comments of that issue. Also thanks to @jbg who gave some input on the subject and @Bruneau who we worked with to get this solved.

I think a (the) highlight of this release is fixing [RSP-27375] Compiler generates disadvantageous code for try/finally - Embarcadero Technologies. Thanks to @Mahdi Safsafifor coming up with a great suggestion and @Stefan Glienkefor creating the issue and pushing hard for its resolution.

Announcing the Availability of RAD Studio 10.4.2 Sydney Release 2 https://blogs.embarcadero.com/announcing-the-availability-of-rad-studio-10-4-2-sydney-release-2/

Register here https://blogs.embarcadero.com/whats-coming-in-10-4-2-sydney/

You forgot one important reason to optimize: The pure fun of it. 😉