COM DLL dumb questions

Hi Blair,

At the risk of getting (way) ahead of myself, let's suppose that I've
deployed some components in a DLL, and somebody starts creating large
numbers of instances from it.  Actually, it might be better to suppose that
I built many compoents packaged into two deployed DLLs.

What happens when executables start creating instances of the components?
In particular, how mwny Dolphin images end up running?  Is it one per DLL,
or do images open based on the callers?  I'm assuming by analogy to exe
servers (multiple use or whatever it's called) that images don't start per
instance??

Are there any restrictions on what the DLL can do?  Can it open MVP triads,
sockets, database connections, etc?
AFAIK, all I'll really need to do is create some "non-visual" controls that
use a proprietary mechanism to scrawl some graphics on an HDC that's
provided to them.  At least, that's that sound of it so far.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> At the risk of getting (way) ahead of myself, let's suppose that I've
> deployed some components in a DLL, and somebody starts creating large
> numbers of instances from it.  Actually, it might be better to suppose
that
> I built many compoents packaged into two deployed DLLs.
>
> What happens when executables start creating instances of the components?
> In particular, how mwny Dolphin images end up running?  Is it one per DLL,
> or do images open based on the callers?  I'm assuming by analogy to exe
> servers (multiple use or whatever it's called) that images don't start per
> instance??

One DLL will be loaded per process. In effect there will be one Dolphin
image running per DLL loaded, regardless of the number of instances of the
components that the DLL in question services. Each individual process is
isolated from all others, so "images" do start on a per process basis.

So the difference from a .EXE server, is that a single .EXE server can
service multiple client APPs. An in-proc server can service multiple
instances, but not multiple applications.

> Are there any restrictions on what the DLL can do?

No, not that I know of.

>...Can it open MVP triads,
> sockets, database connections, etc?

Yes. Remember that when in development mode you will effectively be running
the development system as an in-proc component, so I think you can see that
there are effectively no limitations.

> AFAIK, all I'll really need to do is create some "non-visual" controls
that
> use a proprietary mechanism to scrawl some graphics on an HDC that's
> provided to them.  At least, that's that sound of it so far.

Let us know how you get on.

Regards

Blair

Blair,

> One DLL will be loaded per process. In effect there will be one Dolphin
> image running per DLL loaded, regardless of the number of instances of the
> components that the DLL in question services. Each individual process is
> isolated from all others, so "images" do start on a per process basis.

That's OS process, not thread?


> So the difference from a .EXE server, is that a single .EXE server can
> service multiple client APPs. An in-proc server can service multiple
> instances, but not multiple applications.

Ok, so if there's one big exe (the expected scenario) that wants to create
hundreds of instances each of many different components all served from one
DLL, then I can do the whole thing with one Dolphin session??  That should
work out nicely.


> >...Can it open MVP triads,
> > sockets, database connections, etc?
>
> Yes. Remember that when in development mode you will effectively be
running
> the development system as an in-proc component, so I think you can see
that
> there are effectively no limitations.

Fair enough.  I'm looking forward to playing with it.

BTW, my flaky unit test problem is starting to look like a tired OS session.
I tried to reproduce the error on two Win98 machines at home (P2-400 and a
K62-650) and got no failures.  In desperation, I tried the same test under
D4 on the offending NT machine, and it failed!  After several breakpoints
and some use of process monitor to open debuggers on other threads,
everything seemed to check out.  I rebooted the machine (it had been a
while) and now I can't recreate the problem.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > One DLL will be loaded per process. In effect there will be one Dolphin
> > image running per DLL loaded, regardless of the number of instances of
the
> > components that the DLL in question services. Each individual process is
> > isolated from all others, so "images" do start on a per process basis.
>
> That's OS process, not thread?

Yes.

> > So the difference from a .EXE server, is that a single .EXE server can
> > service multiple client APPs. An in-proc server can service multiple
> > instances, but not multiple applications.
>
> Ok, so if there's one big exe (the expected scenario) that wants to create
> hundreds of instances each of many different components all served from
one
> DLL, then I can do the whole thing with one Dolphin session??
>...

Yes.

> ...
> BTW, my flaky unit test problem is starting to look like a tired OS
session.
> I tried to reproduce the error on two Win98 machines at home (P2-400 and a
> K62-650) and got no failures.  In desperation, I tried the same test under
> D4 on the offending NT machine, and it failed!  After several breakpoints
> and some use of process monitor to open debuggers on other threads,
> everything seemed to check out.  I rebooted the machine (it had been a
> while) and now I can't recreate the problem.

Its worth thinking about whether that suggests it is some timer related
issue. The millisecond clock, for example, is based on uptime. It cycles
after about 49 days, but it will become a LargeInteger value after only
about 12.5 days. Maybe this is relevant, but I'm not sure why.

Regards

Blair

Blair,

> > Ok, so if there's one big exe (the expected scenario) that wants to
create
> > hundreds of instances each of many different components all served from
> one
> > DLL, then I can do the whole thing with one Dolphin session??
> >...
>
> Yes.

Great!


> > BTW, my flaky unit test problem is starting to look like a tired OS
> session.
> > I tried to reproduce the error on two Win98 machines at home (P2-400 and
a
> > K62-650) and got no failures.  In desperation, I tried the same test
under
> > D4 on the offending NT machine, and it failed!  After several
breakpoints
> > and some use of process monitor to open debuggers on other threads,
> > everything seemed to check out.  I rebooted the machine (it had been a
> > while) and now I can't recreate the problem.
>
> Its worth thinking about whether that suggests it is some timer related
> issue. The millisecond clock, for example, is based on uptime. It cycles
> after about 49 days, but it will become a LargeInteger value after only
> about 12.5 days. Maybe this is relevant, but I'm not sure why.

Ok, I'll keep that in mind.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]