Stefan Matthias Aust wrote:
> static struct VirtualMachine *VM;
>
> EXPORT
> int setInterpreter(struct VirtualMachine *interpreterProxy) {
>         VM = interpreterProxy;
>         return 1;
> }
> 
> EXPORT
> void test(void) {
>         int test = VM->stackIntegerValue(0);
>         VM->popthenPush(1, VM->integerObjectOf(-test));
> }

I haven't looked into the latest pluggable primitive stuff, but the
approach implied in this code concerns me for use in a Windows DLL. When
exactly does "setInterpreter" get called? By whom? How often if you are
running multiple Squeak EXEs?

A Windows DLL shares its globals with all users of it. Assume
"setInterpreter" is called once by each EXE using the DLL. This would
mean that if you started up two Squeak sessions, the second one would
also set its interpreter, setting the shared global variable. This means
calls by the first VM to "test" afterward would now internally use the
reference to the second VM, which because of address space issues may
point to garbage instead of either VM.

It is my understanding that the "right" way to do this under Windows to
allow multiple sessions to use the same DLL is to pass a pointer to the
VM into every call.

Remember: the stack used by DLL functions is provided by the caller; the
global variable space is shared by all users of the DLL (and is unique
to the DLL).
Also, remember that since different Windows processes may have different
address spaces, a valid pointer in one address space may point to
garbage in another address space unless the pointer is explicitly
created as shared memory. I believe the address space is always resolved
relative to the caller.

Note that the code above is completely valid and appropriate if it is
statically linked into the VM. In that case, it would share the VM's
global space, and a new global storage location for the modules VM
pointer would of course then be allocated for every new application
process running the VM

Note also that the above code might also be valid in a DLL if the VM was
a shared resource used by all callers of the DLL. This would be valid in
the case where all Squeak EXEs shared one running shared VM, and
multi-threading issues were resolved using locks and semaphores (perhaps
with the DLL function getting a lock on the VM before proceeding), VM
calls were rentrant, and any namespace issues were resolved. I believe
this is now the case with Python (whose VM is in a DLL under Windows) --
but as I understand it was tough sledding to do it and it requires care
in its use. This takes us back to some post years ago on this list
related to the difficulty of adding reentrancy in Squeak...

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com