Externals written in not(c)

Gordon Webster gwalias-rev at yahoo.com
Tue Jan 4 17:29:27 EST 2005


Dear Revolutionaries

I have downloaded the externals SDK from the rr
website and I have trawled through the docs. It
clearly says that you can write an external in any
language of your choosing provided that the
compilation supports certain features that are
essential for the rev interface.

The docs describe in great details what is needed to
create an external in C, but what if I was doing it in
another language whose compiler can produce the kind
of standard "vanilla" DLLs that rev needs?

I can see that I need something called XTable that
defines the separate XCMDs and XFCNs, but I can't
figure out how much of the C header files I need just
to do the simple "feasibility study" of writing a DLL
that say - exports a simple function that reads 2
params, multiplies them together and returns the
result.

I guess what I'm after is a basic minimal list of
features that rev needs in my DLL to be able to do
this simple test - just enough to get me started and
see how it all works. I would like to understand the
process by which the rev engine and the DLL "shake
hands", i.e. initiate their interaction and share
data.

I was thinking of trying a dialect of Basic which can
produce native DLLs - anybody out there have any
insights? 

Can rev read/write data in specific areas of memory? 

I am presuming that sharing memory between processes
is a no-no and that all the rev gurus on this list are
muttering and shaking their heads in disapproval right
now at the very mention of it. I ask because many
languages have the capability to allocate and
read/write in specific areas of memory and it is
another way to communicate between processes. I'm not
even sure that rev can do this - can it?

My goal in all of this? 

Having natively compiled scientific/math libraries
that run at blazing speed behind my rev app, doing the
donkey work on the numbers while rev seduces the user
with its enchanting interface.

All help would be greatly appreciated.

Best

Gordon



More information about the Use-livecode mailing list