dll help needed

Ok, so situation in hand is that I need to provide C callable functions from
dll. As far I was able to find inside newsgroup, Lagoon can only be used to
deploy COM dll's. Is that still the fact? Are there any ways to get dll with
some callable functions, like deploay as com dll, and then add some stuff?

If not, is it a way to deploy COM dll, and create small dll that converts c
calls to COM calls in dolphin  generated dll? Is that something non COM
person could do? What langauge/tools would be best suited to do that?

Any other option?

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Rush,

This is not quite (ok, at all<g>) what you asked, but how much harder is
it for a C programmer to use a COM server than a DLL?  It might even be
easier to use a COM server, because any separate interface pointers to
objects with their own internal state replace structures and memory
management needed to keep things straight for calls to C functions.

If that won't fly with your customer(s), then you should be able to
write a DLL that flattens the objects.  The result might be more
familiar to them, but I would be surprised if it is actually simpler.
If you take that approach, you might be able to get Dolphin to write the
DLL source for you.

The above reminds me of my standing wish for a simple IDE framework for
Dolphin.  Bob Jarvis' ExternalProcess is great, but it would be nice to
have a way to optionally let us see how a build is going and cancel if
error messages are being generated faster than instructions :)  I
currently do a poor job of driving Inno Setup and LaTeX from Dolphin,
and can envision adding MIDL and MinGW to the list.

Have a good one,

Bill


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

"Bill Schwab" <[hidden email]> wrote in message
news:ddg86s$10o2$[hidden email]...
> Rush,
> This is not quite (ok, at all<g>) what you asked, but how much harder is
> it for a C programmer to use a COM server than a DLL?  It might even be
> easier to use a COM server, because any separate interface pointers to
> objects with their own internal state replace structures and memory
> management needed to keep things straight for calls to C functions.

I am afraid interface is not negotiable at all :) , I doubt that second
largest software company in the world might be interested to sit at table
with me and discuss what they should change in one of their interfaces in
order to link to my tiny piece of software :) World is just not right!

> If that won't fly with your customer(s), then you should be able to
> write a DLL that flattens the objects.  The result might be more
> familiar to them, but I would be surprised if it is actually simpler.
> If you take that approach, you might be able to get Dolphin to write the
> DLL source for you.

thanks!

> The above reminds me of my standing wish for a simple IDE framework for
> Dolphin.  Bob Jarvis' ExternalProcess is great, but it would be nice to
> have a way to optionally let us see how a build is going and cancel if
> error messages are being generated faster than instructions :)  I
> currently do a poor job of driving Inno Setup and LaTeX from Dolphin,
> and can envision adding MIDL and MinGW to the list.

Hm subversion and c preprocessor also come to my mind.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Bill, Rush,

> If that won't fly with your customer(s), then you should be able to
> write a DLL that flattens the objects.  The result might be more
> familiar to them, but I would be surprised if it is actually simpler.

I'm far from being COMpetent, but I /think/ that there would be problem here.
Unless you can require the calling program to initialise COM on each thread
that will use your DLL, or alternatively to guarantee that your DLL will only
even be called from one thread /and/ that nothing else called from that thread
(including other DLLs) will use COM, then you are a bit stuck.  Without the
first guarantee you know that you have to call CoIntializeEx() yourself, but
without the second you cannot safely call it.  So you are pretty much (as I
understand it) forced to fork off your own private thread (perhaps in
DllMain()) which will initialise COM for /that/ thread, but then your will have
to make your public DLL entry-points transfer the requests across to that
thread, and wait for it to invoke COM and pass back a result.

Pretty messy, but -- as Bill says -- you could make it more interesting (if not
less messy) by generating the boilerplate code directly from Dolphin's
TypeLibraryAnalysers (or whatever they're called).

BTW, are you (rush) trying to write a Windows "service" in Dolphin ?  If so
then it may be worth mentioning that the Windows documentation warns against
using COM to implement services.  I can't remember the justification, but if
you're interested I'll try to find the reference again.

    -- chris

Hi,

I think in the today multilanguage environments it would be fine to be
flexible in both directions. I mean: calling an exterrnal dll is really
easy, and presenting the strength of Dolphin to the outer environment
by ??? would be also fine. (In my mind the vision is a
multiagent/multimachine/multilanguage environment what I plan in the
longterm)

So what can be put in the place of ???

Thanks,
Janos

"Chris Uppal" <[hidden email]> wrote in message
news:42fc4eb1$0$38038$[hidden email]...
> I'm far from being COMpetent, but I /think/ that there would be problem
here.
> Unless you can require the calling program to initialise COM on each
thread
> that will use your DLL, or alternatively to guarantee that your DLL will
only
> even be called from one thread /and/ that nothing else called from that
thread
> (including other DLLs) will use COM, then you are a bit stuck.  Without
the
> first guarantee you know that you have to call CoIntializeEx() yourself,
but
> without the second you cannot safely call it.  So you are pretty much (as
I
> understand it) forced to fork off your own private thread (perhaps in
> DllMain()) which will initialise COM for /that/ thread, but then your will
have
> to make your public DLL entry-points transfer the requests across to that
> thread, and wait for it to invoke COM and pass back a result.

I was also concerned about threading issues, but the interface does give me
some control over that, (i.e. lets me choose how can I be called). But still
I will have to see if that is enough. If dll->COM will not work I could
perhaps try some IPC to talk from dll to Dolphin code. It is a pitty that it
gets this hairy.

> Pretty messy, but -- as Bill says -- you could make it more interesting
(if not
> less messy) by generating the boilerplate code directly from Dolphin's
> TypeLibraryAnalysers (or whatever they're called).

it is interesting, but I am not sure it would be worthwile, it is only 5-6
functions.

> BTW, are you (rush) trying to write a Windows "service" in Dolphin ?  If
so
> then it may be worth mentioning that the Windows documentation warns
against
> using COM to implement services.  I can't remember the justification, but
if
> you're interested I'll try to find the reference again.

thanks, but it is not for windows service. It is some sort of plugin/adapter
for accounting app that has grown up to such gigantic proportions so that it
now almost has its own meta operating system :)

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Janos Kazsoki wrote:

> I think in the today multilanguage environments it would be fine to be
> flexible in both directions. I mean: calling an exterrnal dll is really
> easy, and presenting the strength of Dolphin to the outer environment
> by ??? would be also fine. (In my mind the vision is a
> multiagent/multimachine/multilanguage environment what I plan in the
> longterm)
>
> So what can be put in the place of ???

Well, that's what COM is supposed to provide, IMO.  Or -- at a more loosely
coupled, but coarser-grained level -- "web services".

Unless you are willing to accept a restriction to one language, or only a small
set of closely related languages -- being allowed to play, then it's difficult
so think of anything that doesn't end up resembling one or the other (or
possibly a hybrid of the two).

You can impose a semantics on the "shared" data/operations as, for instance,
COM imposed an OO-like semantics.  That works reasonably well for languages
which themselves have (more or less) OO semantics, witness Dolphin's COM
integration, but less well for languages that don't "think in objects".  Or you
can go for a highest-common-denominator approach where the shared semantics is
just something that /everyone/ understands -- nested sequences of strings, for
instance -- which is the web services approach.

The other way, I suppose, is to "do a Microsoft" and say that henceforth all
languages shall all run on one VM.  That solves the interoperabability problem,
but at the cost of making all the languages into mere skins over the underlying
VM's semantics.

    -- chris