Anything I can say on this topic is that it works well to move more and more stuff moved from the VM to the image and once you are used to it you will see that writing external DLL's/plugins is cumbersome and only required in special cases.
Writing a plugin doesnt mean you have more memory security since it can have a bug too. Also look at the long development cycle using C/C++ and the need to set up the tools correctly.
Yes, I know there is Smalltalk/X where you can write C directly in the method body - but I still think Smalltalk has more power here.
And it works well to do most stuff in Smalltalk itself:
Look at Smalltalk/MT - you can easily call API functions in Smalltalk style:
WINAPI MessageBox: 0 with: szText with: szTitle with: 0.
Here is an example method and since it is directly in Smalltalk(MT) it is easily changeable and debuggable:
formatError: uError " Formats an error string, given the error code. Parameters: uError A system error code Return Value: A String with an error description. " | count pBuffer answer| pBuffer := LONG localNew. count := WINAPI FormatMessage: FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER with: NULL " ignored " with: uError with: NULL " language identifier " with: pBuffer basicAddress with: 1 " minimum number of characters " with: NULL. count == 0 ifTrue: [ _DEBUG_USER == TRUE ifTrue: [ (WINAPI GetLastError) ~= uError ifTrue: [ ^self formatLastError ]. ]. ^String wsprintf: 'System Error 0x%x' with: uError ]. answer := String fromAddress: pBuffer. WINAPI LocalFree: pBuffer. ^answer
Smalltalk MT also provides the ability to expose a method/block as callback to external code - just put it in a special "callback" method category.
In Smallscript/S# it was even more easier to do since David Simmons allowed you to mix syntax styles and import libs into namespaces:
User32::RegisterWindowMessage('WM_ATLGETCONTROL').
Also see http://double.co.nz/smallscript/unofficialfaq.htm
With an easy to use FFI/Callback mechanism Smalltalkers would be able to integrate more with the platform. I think this is one of the major problems for acceptance of Smalltalk. Where is Squeak's COM binding, interfacing with the window system, ...
Currently only a few of us really integrate with the outside world because they know how to write plugins... It is just to cumbersome how it is today!
I agree with others here: we have the power and tools in Smalltalk and should move more and more stuff to the image. Make it run, make it right and then make it fast (and only in the worst case with a custom plugin written in C).
Bye T.