[Vm-dev] [Vm-beginners] Stability of the external plugin interface

tim Rowledge tim at rowledge.org
Tue May 26 16:55:30 UTC 2020



> On 2020-05-26, at 4:20 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
> On 26/05/20 2:20 am, tim Rowledge wrote:
>>> But this was at process level. If only I could do the same with
>>> DLLs. If only Squeak had a tool (ELF reader?) to reify a DLL,
>>> extract its instruction set, interface definitions, state variables
>>> and calling conventions. Then I can livecode a class and
>>> dynamically compile it (now that we have JIT) to call functions DLL
>>> without leaving the image. The code may not be 'portable' in
>>> traditional sense. But it will be a lot more manageable than static
>>> designs.
>> VW has a parser of C header files that is I suppose the right way to
>> do this sort of thing - you parse the headers (warning - I seem to
>> recall parsing 'windows.h' taking several days in the original VW ddl
>> product) and build proxies of all the types/structs/etc.  Is that a
>> practical way to do it? Hell of a lot of work to do, certainly.
> 
> We don't know what source code was used to compile the DLL.

Certainly true in a lot of cases; the idea used to be that you could get a header file that described the interface and so compile appropriate code. I'm sure there are plenty of cases where that is not what actually happens.

> Having an inspector for DLLs would be a good start. If we pull out the dynamic link maps into the image, then we can simulate in the image, what VM currently does through dlopen() calls. Like what we do in doPrimitive.

That would be nice. And of course Apple bundles, unix .so's and RISC OS shared libraries. A small matter of programming :-)


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Magister Mundi sum! = I am the Master of the Universe!




More information about the Vm-dev mailing list