[Vm-dev] Stupidifying FFI/library loading mechanism

[Igor Stasenko]

On 26 May 2011 23:35, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>
> On 26.05.2011, at 20:41, Denis Kudriashov wrote:
>
> Hello
>
> 2011/5/26 Igor Stasenko <siguctua at gmail.com>
>>
>> loadInternalModule: moduleName
>> loadExternalModule: moduleName path: pathToModuleLibrary
>>
>> and by analogy, for FFI:
>>
>> loadExternalLibrary: pathToExternalLibrary
>>
>
> Can you explain what the difference between this kind of module loading. Why not enough just loadLibrary: pathToLibrary?
>
> VM modules are not just arbitrary libraries. They provide primitive Smalltalk methods. They have special entry points like setInterpreter to be able to interface with the VM directly. Their location is known to the VM. Internal modules are already loaded. But they are still only "activated" when one of their primitive is called. They do the name-to-function-address mapping on their own rather than using the OS's name resolution mechanism.
> Libraries loaded using FFI are just C libraries, nothing special about them. The provide C functions. Name lookup is done using OS functions. The VM can only guess about their location. Igor was proposing to take the guessing out of the VM and put it into the image.

What i finding fun that once you load B3D plugin, it already loads GL
library, because it is linked with it.
But it doesn't means that FFI can locate/use it :)

> - Bert -
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.