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 enthusiasm. 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. -- http://sc3d.org/rrt/ | impatience, n. the urge to do nothing