I’m currently working on a TLS / SSL implementation and on windows I 
am planning to support the Certificate Store that is built in.  This 
requires me to use the CryptoAPI dlls.  The code is complex and it 
uses a number of header files and many steps.  I built some C++ code 
that does what I’m looking for so now I would like to incorporate this 
into Squeak.

I’d assumed that FFI was like DDL/C connect in VW but that’s not what 
I’m seeing.  So my question is: What is the best way to get this 
working?  Should I hack away at FFI and support the api directly, and 
is that even possible?  Should I create DLL’s to call and use them 
with FFI, or should I compile some sort of plugins?  My preference 
would be to call the api directly without having to create dll’s, 
duplicating my C++ code in Smalltalk if possible.

---

Well I've done all three, or is that four?

a) FFI class via platform specific instances interfacing to generic
classes that a squeak user interacts with.

b) FFI class/subclasses that are modified on the fly depending on
platform to get module name correct and or provide overrides by
platform, lots of this in Croquet.

c) wrapper classes that use plugin code that lightly wraps api,
support work all done in Smalltalk, I did this for the extended serial
support.

d) Generic classes that wrap plugin code that interfaces to platform
specific code, lots of this in the VM

Issues.

Generally getting folks to setup a development system, get VMMaker,
understand plugins, build and test something is only done by a
minority of squeakers.

In using FFI, mapping the parms/return values to the correct Smalltalk
external objects will at some point drive you crazy, it does all work,
but sometimes late at night you wonder. For the most part we do this 
in Sophie, any one can do FFI, but debugging is hard.

Using lightly wrap APIs, that provides a bit clearer, in my opinion,
parameter specifications that then invoke the api. You usually can use
the development system source debugger to halt and debug at the api
inteface. It's a bit easy for folks to assemble features since they
can code the steps in smalltalk and interface to the apis, new apis
require someone to mangle plugin code and compile plugins. Technically
it's very similar to FFI, but avoids FFI.

Using fully abstracted plugin with platform specific code, well that's
hard, and few folks want to participate. You can of course write all
the code via plugin code, I believe I do this for the mac menu bar
plugin since it's platform specific, there is no platform C code,
everything is done in squeak slang then compiled into the VM as the
mac menu bar plugin (used in Sophie btw).

John M. McIntosh