Andreas wrote:

This is the first time I've ever heard of something like it. However, it looks like this is a custom VM, no? If it is, I would recommend running one of the release VMs instead to see if you get the same problem or not. If you don't, then I think it's safe to assume that the problem is related to whatever modifications you've been doing.

Fair point. I've now confirmed that the problem occurs with VMs as supplied with 3.9 (Sept 2004) and 3.10 (Aug 2007).

The reason for this problem being intermittent seems to be that it depends on what DLLs you've loaded, and whether any of them happens to be occupying the address space normally used for the DLL you want to load now. It seems like something of a lottery. But perhaps the fact that I'm normally running inside Internet Explorer, and loading a bunch of other DLLs, makes such clashes more likely? Otherwise it's odd that no-one else is seeing this.

Meanwhile, Korakurider pointed me to the following information about DLL-relocation problems with gcc:

By quick googling I found http://oakham.cs.ucl.ac.uk/pipermail/sumover-dev/2009-January/000982.html that shows similar symptom and (possible) root cause.

...

...

"The problem is that DLLs generated by MingW GCC (with -shared) are not

correctly relocatable, even though they contain relocation information. LoadLibrary() returns ERROR_NOACCESS if it is forced to relocate the

DLL

...

and a backtrace shows a blind jump into bad memory from __gcc_register_frame. "

So it looks like there is some precedent for this kind of problem - though I can't tell whether our situation quite matches this one. For a start, they are talking about a later release of gcc.

Anyway, I've now managed to install the ProcessWrapper plugin source and build my own dll. The problem remains as before, which wouldn't be surprising if my build environment is basically the same as for the distributed version. The question is (I guess) whether I can now flick some switch to create a version that doesn't barf when relocated.

(One thing I notice is that the new DLL is larger than the distributed one: 121344 bytes cf 115712. Presumably some difference in the C or CXX flags? For the record, mine are as seen here:

gcc -c -g3 -O3 -mpentium -mwindows -fomit-frame-pointer -funroll-loops -fschedule-insns2 -I. -I../.. -I../../vm -Ic:/dx7sdk/include -DLSB_FIRST -DX86 ProcessWrapperPlugin.c

g++.exe -c main.cpp -o main.o -g3 -O3 -mpentium -mwindows -fomit-frame-pointer -funroll-loops -fschedule-insns2 -I. -I../.. -I../../vm -Ic:/dx7sdk/include -felide-constructors )

Ok, so... it seems that Squeak VM-building tools are based on gcc 2.95. If the relocation problem is related to gcc, and if it was fixed in a later release, is it a simple matter for me to install that instead? Presumably I wouldn't need to use the new compiler for the VM, but just the external DLLs.

Thanks -

Aran