In message , Stuart McKears
writes
On Wed, 23 Mar 2005 14:36:32 +0000, Tony Morgan
wrote:

DLLs are specifically intended to be swapped in and out between memory
and hard disk while a program is actually running. If it weren't so then
their function(s) would be coded in the main program.

I'n afraid that is incorrect. DLLs are what they say they are, libraries of
routines that can be used by various modules at the same time. The only
safe way
to communicate with the OS is via DLLs.

I'm currently using Agent which has loaded or is using 41 DLLs while
IE6 uses 97
if I can count correctly

A useful program for looking at things like this can be downloaded from
www.sysinternals.com

It's worth looking at what the MS KB says about dynamic [1] DLLs. A
search there will reveal that they are swapped in and out of memory, as
required by the calling program. I assume that you will accept that
Microsoft should know what they're talking about? And in respect of
communicating with the OS, aren't you referring to APIs, not DLLs?

[1] static DLLs are restricted to 64KB in data or program
segment, so aren't extensively used.
--
Tony Morgan
http://www.rhylonline.com

In message , Laurence Payne
writes

DLLs are specifically intended to be swapped in and out between memory
and hard disk while a program is actually running. If it weren't so then
their function(s) would be coded in the main program.

DLLs are code modules available to any program that wants them.
What additional DLL would suddenly be required mid-way through a video
capture session?

I'd suggest that you do a search on MS KB.
--
Tony Morgan
http://www.camcord.info

In message , Laurence Payne
writes

DLLs are specifically intended to be swapped in and out between memory
and hard disk while a program is actually running. If it weren't so then
their function(s) would be coded in the main program.

DLLs are code modules available to any program that wants them.
What additional DLL would suddenly be required mid-way through a video
capture session?

It is, for instance, common practice to put to put error-handling
routines in (one or more) DLLs.

I'd also hazard a guess that the capture process itself is a DLL called
from the executive. There seems little virtue in carrying editing
functionality in memory while capturing, or vice versa. Ditto with the
rendering functionality.

Building an application through a number of DLLs serve two purposes, it
minimised the demands on available memory, and it makes debugging a
damned sight easier. And when (as often happens) an application is
designed and coded by a number of software engineers, it make the
demarcation and project management much easier.

--
Tony Morgan
http://www.camcord.info

On Thu, 31 Mar 2005 15:45:53 +0100, Tony Morgan
wrote:

n message , Stuart McKears
writes
On Wed, 23 Mar 2005 14:36:32 +0000, Tony Morgan
wrote:

DLLs are specifically intended to be swapped in and out between memory
and hard disk while a program is actually running. If it weren't so then
their function(s) would be coded in the main program.

I'n afraid that is incorrect. DLLs are what they say they are, libraries of
routines that can be used by various modules at the same time. The only
safe way
to communicate with the OS is via DLLs.

I'm currently using Agent which has loaded or is using 41 DLLs while
IE6 uses 97
if I can count correctly

A useful program for looking at things like this can be downloaded from
www.sysinternals.com

It's worth looking at what the MS KB says about dynamic [1] DLLs. A
search there will reveal that they are swapped in and out of memory, as
required by the calling program. I assume that you will accept that
Microsoft should know what they're talking about? And in respect of
communicating with the OS, aren't you referring to APIs, not DLLs?

Of course, I accept that MS know what their talking about - well some of the
time anyway.

I very carefully quoted your exact paragraph which connected the way the main
program is written with the fact that DLLs are swapped in and out of memory.

As I said that is incorrect, the programmer has little control about whether a
DLL is swapped in/out memory, this is down to OS memory management.

As I, also, said the reasons for using calls to DLLs is because they expose an
interface, detailed in the API, to the OS which the programmer can use or
interrogate. Originally, compilation in high level languages was only possible
if you specified the name of the DLL in the call syntax.

If you're writing your own DLL for a program, a usual reason is for it to
contain common code and/or data used by other modules of your program and/or 3rd
party programs which can be easily accessed by using a DLL's interface.

Stuart

www.mckears.com
www.oldfart.tv - have your say about the state of UK Television

On Thu, 31 Mar 2005 16:18:07 +0100, Tony Morgan
wrote:

I'd also hazard a guess that the capture process itself is a DLL called
from the executive.

That is correct. Video capture is actually done by the OS via DirectX.

Do search on google for - Video Capture DirectShow

Stuart

www.mckears.com
www.oldfart.tv - have your say about the state of UK Television