New InstallShield: no more DLLs

Reuben Thomas
Fri, 8 Dec 2000 10:54:37 +0000 (GMT)

> Did you already try out a statically linked, stripped DLL on Win2K? Do
> you get the same
> error?

Yes, I did, and I didn't get the error. (At least, not after the latest
round of debugging.)

> Do you have some idea what's wrong here?

Only the idea I had before: that something is going wrong during DLL
startup. The best suggestion I've seen is that there's a problem with trying
to use the value of uninitialised pointers, and that when they lie within the
application address space there's no problem, but when they lie outside, an
error is raised. The only guess I have as to why this could be happening (on
our side) is the hack used to allow static initialisers in DLLs.

On the other hand, there is definitely a problem with the linker, which
creates different executables depending on the order in which the libraries
are stored on the disk. I'm not sure whether this is causing problems;
indeed, the fact that the current problem occurs on some machines and not on
others suggests that it is not. It is nevertheless weird, and *can* make the
difference between the problem occurring or not (as it did on my machine).
So it's a sufficient but not necessary cause.

For the moment I'm not investigating this. I will again when I can find the

There's one thing that worries me about your message: are you saying that
you can reproduce the problem with a statically linked DLL? I've only ever
had the problem with dynamic DLLs. That's one reason that I've given up on
it for the moment: it is still possible to use DLLs reliably, as far as I'm
concerned. I thought that Arjan only had problems, as I did, with the
dynamically linked version. If this is false, I'd better dig a bit more.

-- | impatience, n.  the urge to do nothing