John,

Thank you very much for your response, it appears that you support DLL's to
wrap and simplify Api's.  This is doable but I wonder about maintainability
and prefer not to push code outside of Smalltalk if possible for that
reason.  Although, I'm sure that it is the easier way to go, and probably
the path I will take.  Also given the cryptographic nature of the code that
I'm writing and the need eventually to have the code certified, adding
another level of code between the MS API and Squeak leaves another layer to
protect.

Thanks again for giving me more to consider,

Ron Teitelbaum

> From: John M McIntosh
> Sent: Sunday, July 30, 2006 2:26 AM
> 
> 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
> ========================================================================
> ===
>