Smalltalk - VisualWorks as DLL

Author

VisualWorks as DLL

Jay O'Connor

2005-10-26, 7:01 pm

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?

Eliot Miranda

2005-10-26, 7:01 pm

Jay O'Connor wrote:

> 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?

Not as yet. I did a prototype in '98 which hasn't been productised.
We're interested in productising something sometime but are stretched
for resources.

How many people want it?

How important is call-in performance? The prototype ran the image in a
separate thread so that call-ins were asynchronous and slow (~3
milliseconds on a 200MHz Pentium, so probably still 100s of microseconds
on contemporary hardware)

Anybody willing to fund development (pay for a person for 6 months to a
year, say $75k to $150k)?

Anyone willing to chip in to fund development?

--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd

Jay O'Connor

2005-10-26, 7:01 pm

Eliot Miranda wrote:
>
>
> Jay O'Connor wrote:
>
>
>
> Not as yet. I did a prototype in '98 which hasn't been productised.
> We're interested in productising something sometime but are stretched
> for resources.
>
> How many people want it?

Basically, I'm trying to allow some Smalltalk code to be accessed by an application written in C++ but the C++
application has a specific interface it expects from a DLL, I was hoping to avoid having to write the DLL in C++.

Take care,
Jay

Thomas Gagne

2005-10-27, 7:02 pm

Eliot Miranda wrote:
>
>
> Jay O'Connor wrote:
>
>
>
> Not as yet. I did a prototype in '98 which hasn't been productised.
> We're interested in productising something sometime but are stretched
> for resources.
>
> How many people want it?
>

This question gets asked here or in the vwnc list every now and again,
and I seem to recall people are always interested in it. It would
increase Smalltalk's accessibility from other languages but I appreciate
there are technical obstacles.

Steven Kelly

2005-10-28, 7:58 am

"Jay O'Connor" <joconnor@cybermesa.com> wrote in message
news:djoeo7$7ap$1@reader2.nmix.net...
> 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

Marten Feldtmann

2005-10-28, 7:02 pm

Why not use the old IP way: open a socket and transfer ASCII values
between two programs. Simple, but - as the world shows - pretty
good way. You do not need to XML, SOAP or add any other overhead -
just simple ASCII ....

Marten

Eliot Miranda

2005-10-28, 7:02 pm

Steven Kelly wrote:
[snip]
>
> But again, can these calls be started when the C program likes,
> without needing Smalltalk to kick-start things?

That's the issue. One wants to load Smalltalk into another running
program, not have Smalltalk load the other program.

As I say there are no technical hurdles. I did a functional prototype
in '98. But we have a resource problem...

--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd

Steven Kelly

2005-10-31, 7:57 am

"Marten Feldtmann" <marten@toppoint.de> wrote in message
news:djtog4$99v$03$1@news.t-online.com...
> Why not use the old IP way: open a socket and transfer ASCII values
> between two programs. Simple, but - as the world shows - pretty
> good way. You do not need to XML, SOAP or add any other overhead -
> just simple ASCII ....

Ah, if only the world were that simple! If our application's data
could be modelled well as ASCII strings, we would probably be using
Visual Basic instead of Smalltalk ;-). Unfortunately, we have a
strongly interlinked web of objects, and the majority of information
held by an object is links to other similar objects, rather than
simple values like strings or integers.

A SOAP-style XML serialization with id and href offers a solution for
serializing object networks that is a) not appallingly horrid (just
horrid!), and b) has at least some claim to being standard. Most
importantly for us, our customers can call the high-level MetaEdit+
API functions directly, with the SOAP frameworks taking care of
serialization issues.

But thanks for the suggestion! I certainly wouldn't use SOAP because
of buzzword value or any other pseudo reason, if there were a simpler
solution that just worked. To make the ASCII way work, I would have
had to invent my own solution similar to SOAP, and my healthy laziness
won against my unhealthy desire to attempt to build perfection myself.

Steve

Thomas Gagne

2005-10-31, 7:57 am

Steven Kelly wrote:
> "Marten Feldtmann" <marten@toppoint.de> wrote in message
> news:djtog4$99v$03$1@news.t-online.com...
>
>
>
> Ah, if only the world were that simple! If our application's data
> could be modelled well as ASCII strings, we would probably be using
> Visual Basic instead of Smalltalk ;-). Unfortunately, we have a
> strongly interlinked web of objects, and the majority of information
> held by an object is links to other similar objects, rather than
> simple values like strings or integers.
>

The approach we took was to make our lives that simple. That is, we
segregated our processing such that objects don't need to communicated
between processes, instead a much simpler ASCII messages are sent
between processes which have divided the workload.

I suspect not all applications can be similarly modeled, but using the
model of a transaction has worked very well for us. It's a model we use
all the way down to the database. At the lowest level our database and
its procedures present an API to our applications and record our
transactions in a comfortably normalized database. Above that we have a
transaction processor which understands more complicated transactions,
fetches the necessary data, asserts the business rules, handles
exceptions, and on success instructs the database what to record.

To communicate to the transaction processor we use a simple, custom XML
format and open source middleware to multiplex transactions across
multiple "worker" processes. Using this set up we can scale-up our
system to the point of maximum DB throughput. It's simple, reliable,
fast, and easier for mortals to comprehend than serialized objects,
SOAP, object persistence, object-relational mappings, or other
technologies that do more to complicate our code than simplify it.

Mike Hales

2005-10-31, 7:02 pm

Smalltalk MT can do this. The licensing is pretty cheap. Most of my
work is in Visual Works, but when I needed to do some work with a bunch
of direct x stuff I built the app in MT. It's way better than doing it
in C++ but it still plays nice with Windows and C++

Mike

perikov@gmail.com

2005-11-03, 7:01 pm

>
> How important is call-in performance? The prototype ran the image in a
> separate thread so that call-ins were asynchronous and slow (~3
> milliseconds on a 200MHz Pentium, so probably still 100s of microseconds
> on contemporary hardware)
>
> Anybody willing to fund development (pay for a person for 6 months to a
> year, say $75k to $150k)?

ability to implement local COM interfaces required by some exe would be

. performance is an issue. Sorry, no funding :( 150K ~ 5 years for
very-very decent developer here. 3 for brilliant, all included :)

Yours, Pavel

Sponsored Links