Re: VisualWorks as DLL

"Jay O'Connor" <joconnor@xxxxxxxxxxxxx> wrote in message
news:djoeo7$7ap$1@xxxxxxxxxxxxxxxxxxx
> Is there anyway to create a VisualWorks image such that it can be
> accessed from other programs as a DLL? If so, how do you defeine
> the interface?

We had a similar requirement when we wanted to add an API to our
product (MetaEdit+ modeling tool built with VW). Since we have
customers on different platforms, we ended up going with SOAP. DLLs
are Microsoft specific, and IIRC they are being phased out. Microsoft
says the standard for interfacing between different programs in
Windows is WebServices i.e. SOAP.

SOAP has worked well for us, but wouldn't be fast enough in all
situations. On a P4 3GHz it takes about 10ms for a one-argument call
passing an object with two integer instance variables and returning a
similar object (about 600 characters each way). Both client and server
are VW 7.3.1, and within the same image (so maybe half the time for
the server end?). And that time is without any proxy server -
depending on your VW, Windows and firewall settings, Windows may want
to proxy the call off to a proxy server, even for a SOAP client and
server on the same machine, which then takes several times longer.

What about the "Calling Smalltalk from C" chapter in
DLLandCConnectGuide.pdf? That seems to only allow C to call Smalltalk
as a callback, i.e. if Smalltalk starts the conversation. I suppose
you could start the conversation via SOAP (or just pressing a button
or something in VW if that's acceptable), and then have the C program
do many callback calls. But is there any way to kick-start the process
from C, with VW already running as a "server", and then the C program
starting up and doing what it likes, when it likes?

What about the "Object Engine Access Functions" chapter? Can we just
call VW VM (Object Engine) "C" functions such as oeCSendMessage0(OEoop
oeReceiver, char *szSelector ...) to call Smalltalk methods? The
szSelector is simply a C string containing the name of the method to
call, but oeReceiver is a bit trickier: how to get the first object
back from Smalltalk? Looks like we can call oeRegisteredHandleAt() to
pick up the OEoop for any object VW has decided to register, so our VW
"server" program could register a bunch of useful objects (or just one
proxy object, as we did in our SOAP case). Alternatively, there are
methods like oeByteStringClass() that return ByteString (the
ByteString object's OEoop), or oeNil() for nil's oeOop, so any method
defined in one of those can be called. And if you can get the string
class, you can create an instance of it and send it
#asQualifiedReference, so you can get any class you like. Get the
SmalltalkCompiler class and you can do anything! (Hmm, "minor"
security risk!)

But again, can these calls be started when the C program likes,
without needing Smalltalk to kick-start things? If so, I might make a
little C wrapper for the existing MetaEdit+ API, so both SOAP and DLLs
can call the same functions. Obviously SOAP is the way of the future,
but then speed is a lust - presumably the Object Engine access
functions would be much faster (need more speed... gotta get me some
of that UNSAFE ;->).

Steve



.