[Vm-dev] LoadLibrary problem on Vista? - supplementary info

[Aran Lunzer]

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