Version 0 of loading from memory

Updated 2002-05-18 16:47:28

interesting discussions on comp.lang.tcl recorded here, prompted by a list of 'helpful projects' for Tcl, see project wish list

> Jeffrey Hobbs <[email protected]> wrote: > > >OS internals: > > * loading DLLs from memory > > What's that? It sounds interesting.

I would mean that a shared library could be loaded directly from an in-memory VFS instead of having to write the library to an actual file and invoking the loader on that.

The problem is that, at least on Solaris, libdl provides no facilities at all for doing this. You'd have to code it yourself. Which make this project a bit involved...

>Hey, I didn't say all the projects were *easy*. :)

My bag of tricks is usually pretty good, but I'll tip my hat to someone who can do this on windows. LoadLibrary() needs a filename. We can cheat and use global object names, like "\\.\pipe\somepipe". Now how do we create a block of process memory as a shared object? We can do the reverse with MapViewOfFile() ... whoa, this is tricky. Whatever happened to ram disks anyways?

You'd of course have to do the loading yourself, rather than with LoadLibrary(), but it looks possible - albeit difficult. The last couple of issues of _MSDN Magazine_ have had the details of the file format, and a discussion of how a DLL image gets mapped. An initial implementation wouldn't need to worry about sharing code segments, who cares about swap space anyway?

Text of the articles is at:

    http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp
    http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/PE2.asp

Sounds very interesting. Loading dlls from ftp servers (or if we ever get to it the great unified tcl tk extension repository (GUTTER, what a disgusting acronym, but you would find real gems in it ;-)) That would be really cool.

This is actually more something for wrapped applications. Sort of pseudo- static linking, but actually dyn. linking

A merge of this with your idea provides extensibility at runtime ... I.e. package require foo, load DLL from the network, save it into the wrapped application, used that in the future. ... The security risks are high. IOW, I will not do that without proper authentication. A wrapped tcl application as the new worm of the century surfing the net, extending itself for any machine architecture it encounters ... Especially if there are services which compile a package on demand for some architecture ...