Board index » delphi » dynamic "uses"

timothy2...@my-deja.com

Delphi Developer
Fri, 25 Apr 2003 03:00:00 GMT

dynamic "uses"

hello,

does someone know who I can implement dynamic "uses",  without DLL's.

I have a .pas-file with plenty of functions in it. Now I want to split
it up, in lets say 10 sub .pas-files, which I call from the head .pas-
file.
The main reason to do that is that I want to be my programs less big
when compiled. But when I use "uses" and the name of the .pas-files I
still have all .pas-files included. So I don't win any space.

So I wonder if someone knows how I can use the "uses" method dynamic?
So that the sub .pas-file is only included/'compiled with' when a
function is called in the main program.

Thanks,

Timothy Verhamme

Sent via Deja.com http://www.deja.com/
Before you buy.

 
M.H. Avegaar

Delphi Developer
Fri, 25 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


The linker will automatically remove unused procedures. So there is no need
to split your unit into several parts, because the result won't be smaller.
There are several other methods to make files smaller (remove debug
information, use runtime packages etc.).

<timothy2...@my-deja.com> schreef in bericht
news:8u66ff$1a7$1@nnrp1.deja.com...

Quote
> hello,

> does someone know who I can implement dynamic "uses",  without DLL's.

> I have a .pas-file with plenty of functions in it. Now I want to split
> it up, in lets say 10 sub .pas-files, which I call from the head .pas-
> file.
> The main reason to do that is that I want to be my programs less big
> when compiled. But when I use "uses" and the name of the .pas-files I
> still have all .pas-files included. So I don't win any space.

> So I wonder if someone knows how I can use the "uses" method dynamic?
> So that the sub .pas-file is only included/'compiled with' when a
> function is called in the main program.

> Thanks,

> Timothy Verhamme

> Sent via Deja.com http://www.deja.com/
> Before you buy.

timothy2..

Delphi Developer
Fri, 25 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


Is the compiler of Borland Delphi 4 as intelligent? I don't think... I
tested several in several ways and came to the conclusion it doesn't
make any difference... He always takes all...

In article <8u686d$c8...@porthos.nl.uu.net>,
  "M.H. Avegaart" <avegaartNOS...@mccomm.nl> wrote:

Quote
> The linker will automatically remove unused procedures. So there is
no need
> to split your unit into several parts, because the result won't be
smaller.
> There are several other methods to make files smaller (remove debug
> information, use runtime packages etc.).

> <timothy2...@my-deja.com> schreef in bericht
> news:8u66ff$1a7$1@nnrp1.deja.com...
> > hello,

> > does someone know who I can implement dynamic "uses",  without
DLL's.

> > I have a .pas-file with plenty of functions in it. Now I want to
split
> > it up, in lets say 10 sub .pas-files, which I call from the head
.pas-
> > file.
> > The main reason to do that is that I want to be my programs less big
> > when compiled. But when I use "uses" and the name of the .pas-files
I
> > still have all .pas-files included. So I don't win any space.

> > So I wonder if someone knows how I can use the "uses" method
dynamic?
> > So that the sub .pas-file is only included/'compiled with' when a
> > function is called in the main program.

> > Thanks,

> > Timothy Verhamme

> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.
Dirk Claessen

Delphi Developer
Fri, 25 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


<timothy2...@my-deja.com> schreef in berichtnieuws
8u6iap$au...@nnrp1.deja.com...
Quote
> Is the compiler of Borland Delphi 4 as intelligent? I don't think... I
> tested several in several ways and came to the conclusion it doesn't
> make any difference... He always takes all...

The cause for this is the Forms unit which is always "used" by all
 non-console ) Delphi applications. If you really need lean exe's, write a
console app, but then you can't have fancy forms (and many other things).
Life's a choice <g>

Always bear in mind that even the simplest "Hello World" app of 300Kb has a
tremendous amount of mostly unnoticed functionality, just to name a few:
- You can move/resize/hide/maximize windows
- Change the system colors => your app will automagically change color.
- Change the system time => your app will be informed
- Close the main form => your app exits
- etc...

...all this without writing _one_ line of code!

--
Regards,

Dirk Claessens
---------------------------------------------------------
http://www.claessens16.yucom.be
Attention: All spamshields raised; E-mails will bounce!
---------------------------------------------------------

Jim Andrew

Delphi Developer
Fri, 25 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


Hello,

Try selecting the "Build with runtime packages" option from the
Project/Options/Packages window.  I made a "hello world" application (button
and text).  The exe was 296K without checking the option and 14K, yes four{*word*249},
one-four K, with the option checked.  Seems this option rebuilds the dcu's for
the included units and only keeps the parts that are used.  THe 20:1 reduction
in size is dramatic.

I found this quite by accident when my exe went from 2.3MB to 1MByte after I
added a non-borland component to my program and thought I had to build it
separately.  This should be better documented as it is a real space saver for
simple programs.

I think once you start to do this you have to do it for all of your programs as
it may re-build the standard units without everything needed for more complex
programs.  Not worth the time required to test it though as now I always use
this option and my exe files are all smaller.

...Jim

Quote
"M.H. Avegaart" wrote:
> The linker will automatically remove unused procedures. So there is no need
> to split your unit into several parts, because the result won't be smaller.
> There are several other methods to make files smaller (remove debug
> information, use runtime packages etc.).

> <timothy2...@my-deja.com> schreef in bericht
> news:8u66ff$1a7$1@nnrp1.deja.com...
> > hello,

> > does someone know who I can implement dynamic "uses",  without DLL's.

> > I have a .pas-file with plenty of functions in it. Now I want to split
> > it up, in lets say 10 sub .pas-files, which I call from the head .pas-
> > file.
> > The main reason to do that is that I want to be my programs less big
> > when compiled. But when I use "uses" and the name of the .pas-files I
> > still have all .pas-files included. So I don't win any space.

> > So I wonder if someone knows how I can use the "uses" method dynamic?
> > So that the sub .pas-file is only included/'compiled with' when a
> > function is called in the main program.

> > Thanks,

> > Timothy Verhamme

> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

Sundial Service

Delphi Developer
Fri, 25 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


Here's the soap on THAT issue, Jim...

[1] The USES clause, by itself, is 100% a "compile time" issue.  It
simply determines what other units (the INTERFACE clause of those
units...) a particular unit might refer to in =its= INTERFACE part.
These are the units that will be compiled first, if necessary.  (The
need for a MAKE file is thus completely eliminated in Delphi.)  [The
need for an occasional "Build All" to really clear things up .. is not
eliminated, but "who cares?  Delphi's f-a-a-a-st!"]

[2] The issue of how the corresponding units -- by this I mean, "the
instructions that the CPU is actually going to -run-" -- get connected
to a particular EXE or DLL is really quite separate(!) from this.  We
know, for instance, that when that EXE or DLL actually gets the
attention of a CPU someplace, "those instructions had durn well better
be available SOMEHOW, SOMEPLACE, or the durn thing's gonna B-L-O-W!"
;-) ;-)  On that score, Delphi (versions 3.0 and higher), offer you
=two= options:  (1) linking it all into the current EXE or DLL; or (2)
packages (which are, simply, DLLs).

...

When you built your app with "runtime packages," Jim, your EXE shrunk to
14K.  That's because it now includes code which will load the
appropriate runtime DLL (package...) and will vector calls to it.  The
14K is "the stuff that is particular to your application."

When you built the same option without packages, the 296K file was
entirely self-contained.  It can run without any runtime-DLLs installed;
the 14K version cannot.  We can therefore reasonably "do the math" and
conclude that the 14K version will refer to approximately 282K-worth of
stuff that's inside that runtime DLL.

Which is better?  Hey, in this world of ump{*word*249}-gigabyte disk drives
(available at Wal-Mart? .. I kid you not!!) it really doesn't matter
much.  It's almost "a difference that makes no difference," =unless= you
are distributing an application, which now must check to see if the
appropriate package-DLLs exist on the target computer or not.  (Much the
same way that Microsoft Visual C++ apps must check for "MSVCRTnn.DLL"
files.)

Runtime packages impose a certain amount of maintenance -- in the end,
there is no such thing as a "free lunch" (read: "those instructions had
durn well better be available SOMEHOW, SOMEPLACE, or the durn thing's
gonna B-L-O-W!") -- but in many cases it's 100% acceptable and "100% a
Good Thing."

The only thing you -cannot- do, Jim, is to ignore the fact that "282K of
object-code has to come from somewhere!"  :-)  No free lunch.  And of
course, if the runtime-package DLL is any larger than precisely 282K
(which, of course, it is!) ... there is actually a net-COST in terms of
disk-space-used.

{But in a world of ump{*word*249}-megabyte disk drives at Wal-Mart .. who gives
a flip, eh?) ;-)

Quote
>Jim Andrews wrote:

> Try selecting the "Build with runtime packages" option from the
> Project/Options/Packages window.  I made a "hello world" application (button
> and text).  The exe was 296K without checking the option and 14K, yes four{*word*249},
> one-four K, with the option checked.  Seems this option rebuilds the dcu's for
> the included units and only keeps the parts that are used.  THe 20:1 reduction
> in size is dramatic.

> I found this quite by accident when my exe went from 2.3MB to 1MByte after I
> added a non-borland component to my program and thought I had to build it
> separately.  This should be better documented as it is a real space saver for
> simple programs.

> I think once you start to do this you have to do it for all of your programs as
> it may re-build the standard units without everything needed for more complex
> programs.  Not worth the time required to test it though as now I always use
> this option and my exe files are all smaller.

> ...Jim

> "M.H. Avegaart" wrote:

> > The linker will automatically remove unused procedures. So there is no need
> > to split your unit into several parts, because the result won't be smaller.
> > There are several other methods to make files smaller (remove debug
> > information, use runtime packages etc.).

> > <timothy2...@my-deja.com> schreef in bericht
> > news:8u66ff$1a7$1@nnrp1.deja.com...
> > > hello,

> > > does someone know who I can implement dynamic "uses",  without DLL's.

> > > I have a .pas-file with plenty of functions in it. Now I want to split
> > > it up, in lets say 10 sub .pas-files, which I call from the head .pas-
> > > file.
> > > The main reason to do that is that I want to be my programs less big
> > > when compiled. But when I use "uses" and the name of the .pas-files I
> > > still have all .pas-files included. So I don't win any space.

> > > So I wonder if someone knows how I can use the "uses" method dynamic?
> > > So that the sub .pas-file is only included/'compiled with' when a
> > > function is called in the main program.

> > > Thanks,

> > > Timothy Verhamme

Jim Andrew

Delphi Developer
Sat, 26 Apr 2003 16:36:32 GMT

Re:dynamic "uses"


Sundial,

Not sure that I agree with you that program size is no longer important.  The disk
space is almost free but the time required to download programs and support files is
not.

Let me see if I understand.  When I build with runtime packages the user then needs
those packages (VCL50.BPL, etc) in their system directory.  If I don't, then I don't
have to distribute them. Can I uncheck ALL of the components listed in the
installshield general options if I don't build with runtime packages?

If this is true then the choice seems to be to distribute the smaller program and the
packages (*.BPL) or a larger program with no BPLs.  In my case it may save time for
my beta test sites to download a smaller program each time a new version is available
rather than downloading much larger programs every time.

...Jim

Quote
Sundial Services wrote:
> Here's the soap on THAT issue, Jim...

> [1] The USES clause, by itself, is 100% a "compile time" issue.  It
> simply determines what other units (the INTERFACE clause of those
> units...) a particular unit might refer to in =its= INTERFACE part.
> These are the units that will be compiled first, if necessary.  (The
> need for a MAKE file is thus completely eliminated in Delphi.)  [The
> need for an occasional "Build All" to really clear things up .. is not
> eliminated, but "who cares?  Delphi's f-a-a-a-st!"]

> [2] The issue of how the corresponding units -- by this I mean, "the
> instructions that the CPU is actually going to -run-" -- get connected
> to a particular EXE or DLL is really quite separate(!) from this.  We
> know, for instance, that when that EXE or DLL actually gets the
> attention of a CPU someplace, "those instructions had durn well better
> be available SOMEHOW, SOMEPLACE, or the durn thing's gonna B-L-O-W!"
> ;-) ;-)  On that score, Delphi (versions 3.0 and higher), offer you
> =two= options:  (1) linking it all into the current EXE or DLL; or (2)
> packages (which are, simply, DLLs).

> ...

> When you built your app with "runtime packages," Jim, your EXE shrunk to
> 14K.  That's because it now includes code which will load the
> appropriate runtime DLL (package...) and will vector calls to it.  The
> 14K is "the stuff that is particular to your application."

> When you built the same option without packages, the 296K file was
> entirely self-contained.  It can run without any runtime-DLLs installed;
> the 14K version cannot.  We can therefore reasonably "do the math" and
> conclude that the 14K version will refer to approximately 282K-worth of
> stuff that's inside that runtime DLL.

> Which is better?  Hey, in this world of ump{*word*249}-gigabyte disk drives
> (available at Wal-Mart? .. I kid you not!!) it really doesn't matter
> much.  It's almost "a difference that makes no difference," =unless= you
> are distributing an application, which now must check to see if the
> appropriate package-DLLs exist on the target computer or not.  (Much the
> same way that Microsoft Visual C++ apps must check for "MSVCRTnn.DLL"
> files.)

> Runtime packages impose a certain amount of maintenance -- in the end,
> there is no such thing as a "free lunch" (read: "those instructions had
> durn well better be available SOMEHOW, SOMEPLACE, or the durn thing's
> gonna B-L-O-W!") -- but in many cases it's 100% acceptable and "100% a
> Good Thing."

> The only thing you -cannot- do, Jim, is to ignore the fact that "282K of
> object-code has to come from somewhere!"  :-)  No free lunch.  And of
> course, if the runtime-package DLL is any larger than precisely 282K
> (which, of course, it is!) ... there is actually a net-COST in terms of
> disk-space-used.

> {But in a world of ump{*word*249}-megabyte disk drives at Wal-Mart .. who gives
> a flip, eh?) ;-)

> >Jim Andrews wrote:

> > Try selecting the "Build with runtime packages" option from the
> > Project/Options/Packages window.  I made a "hello world" application (button
> > and text).  The exe was 296K without checking the option and 14K, yes four{*word*249},
> > one-four K, with the option checked.  Seems this option rebuilds the dcu's for
> > the included units and only keeps the parts that are used.  THe 20:1 reduction
> > in size is dramatic.

> > I found this quite by accident when my exe went from 2.3MB to 1MByte after I
> > added a non-borland component to my program and thought I had to build it
> > separately.  This should be better documented as it is a real space saver for
> > simple programs.

> > I think once you start to do this you have to do it for all of your programs as
> > it may re-build the standard units without everything needed for more complex
> > programs.  Not worth the time required to test it though as now I always use
> > this option and my exe files are all smaller.

> > ...Jim

> > "M.H. Avegaart" wrote:

> > > The linker will automatically remove unused procedures. So there is no need
> > > to split your unit into several parts, because the result won't be smaller.
> > > There are several other methods to make files smaller (remove debug
> > > information, use runtime packages etc.).

> > > <timothy2...@my-deja.com> schreef in bericht
> > > news:8u66ff$1a7$1@nnrp1.deja.com...
> > > > hello,

> > > > does someone know who I can implement dynamic "uses",  without DLL's.

> > > > I have a .pas-file with plenty of functions in it. Now I want to split
> > > > it up, in lets say 10 sub .pas-files, which I call from the head .pas-
> > > > file.
> > > > The main reason to do that is that I want to be my programs less big
> > > > when compiled. But when I use "uses" and the name of the .pas-files I
> > > > still have all .pas-files included. So I don't win any space.

> > > > So I wonder if someone knows how I can use the "uses" method dynamic?
> > > > So that the sub .pas-file is only included/'compiled with' when a
> > > > function is called in the main program.

> > > > Thanks,

> > > > Timothy Verhamme

Jim Andrew

Delphi Developer
Sat, 26 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


One more question on builds.

I assume that, when using InstallShield, the BDE object is always required if the
application uses the BDE.  This seems to load the BDE DLLs, BDEADMIN and aliases.  If I
build my program without using packages, do I need to include any of the other objects
(ie. VCL50.BPL) in the distribution?  I don't have access to a {*word*269} system right now to
test what is required and what is not to run my exe.

It still may be a trade-off as I save 1.4MByte for the original distribution by not using
packages but add 1MByte each time a new version of the program is sent.

...Jim

Bj?rge S?the

Delphi Developer
Sat, 26 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


"Jim Andrews" <j...@azdogs.com> skrev i melding
news:3A07BF0F.7A00AA85@azdogs.com...

Quote
> Let me see if I understand.  When I build with runtime packages the
user then needs
> those packages (VCL50.BPL, etc) in their system directory.  If I
don't, then I don't
> have to distribute them.

Correct. Well, almost. You don't need to put the packages in system
directory, anywhere on your path is sufficient.

Quote
> If this is true then the choice seems to be to distribute the smaller
program and the
> packages (*.BPL) or a larger program with no BPLs.  In my case it may
save time for
> my beta test sites to download a smaller program each time a new

version is available

Quote
> rather than downloading much larger programs every time.

A few points on decision whether to use runtime packages (RTP):
- Smaller .exe file to up / download *with* RTP
- Some 1-2 sec. slower on startup *with* RTP from local HDD
- More complicated client installation *with* RTP (not *very*
complicated, only need to copy .bpl files)
- The real benefit with RTP is when you build an app concisting of
several modules (dll's), or when you are running more Delphi apps on
same machine (compiled with same Delphi version, that is) - faster load
& less footprint
- Some of us have problems with debug functionality when compiling with
RTP, I for mine have (tempoarily) given up package debugging.

--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether.removet...@online.no (remove the obvious)

timothy2..

Delphi Developer
Tue, 29 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


Hello,

now I have a file named 'functions.pas' with all my self-made functions
in. When I use this in a program, their is soon 450kb extra. I want to
reduce that, but I want that I just have the call 'functions.pas' in my
main-program, and that 'functions.pas' goes to other '.pas'-files to
get the function from there.

-- so 'functions.pas' should be a redirector between the main-program
-- and the splitted '.pas'-files.

I can do this, this isn't a problem, but when I use this my '.exe'-
files become (offcourse) bigger. But is there a manner so that the
'functions.pas' only includes the '.pas'-files with used functions from
the main-program ...

thanks,

Timothy Verhamme.

Sent via Deja.com http://www.deja.com/
Before you buy.

Bj?rge S?the

Delphi Developer
Tue, 29 Apr 2003 03:00:00 GMT

Re:dynamic "uses"


<timothy2...@my-deja.com> skrev i melding
news:8ugb0v$eug$1@nnrp1.deja.com...

Quote

> now I have a file named 'functions.pas' with all my self-made
functions
> in. When I use this in a program, their is soon 450kb extra. I want to
> reduce that, but I want that I just have the call 'functions.pas' in
my
> main-program, and that 'functions.pas' goes to other '.pas'-files to
> get the function from there.

> -- so 'functions.pas' should be a redirector between the main-program
> -- and the splitted '.pas'-files.

> I can do this, this isn't a problem, but when I use this my '.exe'-
> files become (offcourse) bigger. But is there a manner so that the
> 'functions.pas' only includes the '.pas'-files with used functions
from
> the main-program ...

A functions.pas with thousands of lines of code doesn't increase program
size more than the size of the routines actually used in your
application. The common problem with a unit like this is what this file
has included in it's uses clause: If it's using DBTDABLES, then your
.exe size will grow by some 250kb, etc... this code can't be "linked
away" (a poor design, if you ask me). For units containing controls, all
code that may be called as a result of some message being sent to the
window, must be present. You never know what messages may be sent from
other applications...this means overhead.

The solution is as follows: Split the routines from your functions.pas
into more units, based on what they need in their uses clause. Start
with the one that needs nothing but SysUtils, Classes, Messages and
Windows .pas files (don't use ShowMessage, it requires the Dialogs.pas,
adding some overhead).

I got the following overhead just by adding the unit (only one at a
time):

DIALOGS.PAS: 2kb
DB.PAS: 6kb
DBTABLES.PAS: 240kb
QUICKRPT.PAS: 556 kb

...all this without a single line of code, it could all be "linked
away"....

--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether.removet...@online.no (remove the obvious)

Other Threads

1. dynamic "uses"

2. dynamic "uses" -- no dll

3. The keys "-"/"+"/"*"

4. Dynamic Date Exchange "DDE" Help

5. Oracle version of "dynamic cursor"?

6. Acces violation on dynamic creating Qreport "A component named QRStandardPreview already exists",

7. "Dynamic" ActiveX (kinda complicated)

8. ""256 Color Mouse""

9. How to initialize "Text"-Property without raising "OnChange"-event

10. How to initialize a "Text"-property without raising an "OnChange"-event