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).


On 29-Jul-06, at 9:15 PM, Ron Teitelbaum wrote:

> Hello all,
>
>
>
> 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.
>
>
>
> Some direction and comparisons of different options would be very  
> helpful.
>
>
>
> Thank you for your help!
>
>
>
> Ron Teitelbaum
>
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===