Re: DCOM Surrogates
From: David Reeve (dree4456_at_big-pond.net.au)
Date: 07/18/04
- Next message: Evil miniFAQ Boss: "FAQ: comp.lang.pascal.delphi.misc miniFAQ (short version)"
- Previous message: Jud McCranie: "Re: teaching a child - console or GUI"
- In reply to: SimonW: "Re: DCOM Surrogates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 18 Jul 2004 00:20:09 GMT
"SimonW" <bozzzza@lycos.co.uk> wrote in message
news:2lseh3Fgmu8sU1@uni-berlin.de...
>
[snip]
> Perhaps I am getting myself confused somewhere on the subject of
in-process
> and out-of-process, on reading the Delphi 6 developers guide: page 33-6, I
> believed it was possible to create a remote-server dll where I did not
need
> to use a surrogate process.
>
Hmm... I've only got the D4 version of the above. But the problem still
stands, you're server has to be instantiated in a runnable process.
> Having reading the previous posts, I think I am beginning to realise that
> the reason we need the surrogate process, even though this may be a
> simplistic and incorrect view, is because DLL's do not have any code to
load
> themselves and rely on a host program to use them.
>
That's right ... the DLL acronym stands for dynamic link library, and a
library is what it is :-)
> I am not quite sure why Microsoft did not create this process
automatically
> when you run regsvr32 on a DLL: they could have set it up so it the DLL
> could be registered with DCOM using the surrogate process.
>
You seem to be getting locked in to the idea of a dll when its an exe you
need. That exe doesn't need to show itself, it can run in the background if
that is what you desire. All you need to do is run the server exe once, or
register it if you like, and it will start running when required by a
client. My normal practice is to start my servers with their forms
minimized, and within a 100msec of start up, remove the reference from the
task bar, and iconize them to the tray. That way the user knows they are
running, but doesn't have to bother with them in the normal course of
events.
> My apologies if I rambled on a bit, or if I have not quite got the idea of
> DLL processes, but I am quite excited about this technology and what it
can
> do, even though this is now, in Microsoft's eyes at least, an obsolete
> technology and has been replaced by some .NET technology, but that is
> another story.
I make extensive use of this technology because it offers modularisation
advantages. I'm involved in instrumentation control, and, automation servers
provide an elegant way of wrapping the functionality of different lumps of
hardware so that they can plug into a common interface provided by my main
application. What happened in the past was that we would migrate to a new
piece of hardware, then have to change the main app to accomodate it. This
caused a version branch, both limbs of which had to be developed and
maintained if one was to support existing customers with the old hardware.
Another advantage they offer is modularisation of presentation code. For
example, my apps involve data streams which need to be represented in all
sorts of graphical ways. I like to keep 99% of my code non-visual such that
connections to the GUI are made only at the topmost level, but it is
difficult to prevent the data displays becoming enmeshed with the workings
below. Then, what happens when you need to change the presentation
layer?..... much pain and gnashing of teeth. However, if you eschew all the
nice functionality offered in the various charting components, and instead
provide the inner workings with non-visual plotting engines crafted to do
exactly what is required, and furthermore, expose these plotting engines as
plotting servers, then suddenly you have a kernel to your app which is
future proofed to quite some degree. If marketing demands a new look GUI, it
is relatively easy to drop a new presentation layer in place and know the
basic behaviour of the app will be unchanged. If a customer wants to view
what is going on from a remote location, no problem, you can hook a small
display app into the appropriate server over his network. Old technology may
be, but still very, very usefull.
Dave
- Next message: Evil miniFAQ Boss: "FAQ: comp.lang.pascal.delphi.misc miniFAQ (short version)"
- Previous message: Jud McCranie: "Re: teaching a child - console or GUI"
- In reply to: SimonW: "Re: DCOM Surrogates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
