Then one needs into account the size of the packages. Here is a look at the sizes (in Byte) for chmls if using dynamic packages I did two months ago:
Yeah, that's, what I want to say. When you count application size - you should always take runtimes into account. For example Win C++ programs are small in comparison to Pascal ones, but we always forget about VS xxxx runtime. Or .Net applications, that also require .Net Framework. Delphi and Lazarus aren't that widespread and they don't have any deals with M$, so their runtimes just aren't treated as "standard". I.e. for example Delphi runtime packages are actually distributed the same way, as VS runtime. I.e. they can also be installed to System32 directory and therefore be available system wide. And after that Delphi applications can also look like "stand alone", while they actually aren't, and therefore look like they're much smaller, than they actually are.
Of course such small size of my Delphi app comes at expense of having:
1) rtlxxx.bpl
32bit - 2.8Mb
64bit - 4.0Mb
2) vclxxx.bpl
32bit - 3.3Mb
64bit - 4.8Mb
3) dyndataxxx.bpl
32bit - 43Kb
64bit - 62Kb
4) dyntestxxx.bpl
32bit - 411Kb
64bit - 546Kb
What's advantage of using packages then? They're
SHARED between applications and their modules. My application has 36(!!!) modules. Without runtime packages they have 2x size. More modules you have - bigger advantage is. Yeah, I know, that all modules can be liked into one single exe in Lazarus. But it doesn't work for Delphi due to 2 reasons: 1) 32bit IDE, that has application/module size limit 2) It's designed around closed source applications.
And IMHO: splitting application between modules - is good development practice, especially for big and complex projects. So it isn't about "favoring proprietary technologies" only.