control.exe starts, hangs around for a few seconds, then dissapears w/out ever starting your dialog.
Looking at your dependencies, I notice something called “GLU_130.dll” that I don’t have. The funtions being called are mangled (i.e., "_gluBuild2DMipmaps@28, _gluGetString@4, etc.) as though they aren’t being exported correctly…?
I note you also have a dependency on the “regular” GLU32.dll.
My guess (and only a guess!): in the depths of control.exe there’s something that walks each .cpl’s dependencies, and it’s failing because this dll can’t be found. But control.exe isn’t putting up a dialog to let us know - instead, it just doesn’t run that app. Probably so you can never open up control panel and get hit with lot’s of “a needed .dll can’t be found” messages if third-party .cpls don’t remove their registry entries when uninstalled.
If that’s the case, then it’s interesting that it runs on NT but not Win2K… Maybe you specified that .dll in your import list, but never call any of it’s functions? So simply running the app wouldn’t cause the (non-existant) .dll to be loaded, thus a less strict control.exe would allow the app to run, and nothing would blow up.
Incidentally, regarding the WinNT vs. Win2K argument: Isn’t the fight supposed to break out between Linux and Windows? Or at least Mac OS and Windows? If we keep drawing these lines, I won’t be able to remember whose side I’m on!!!
I used to run NT4 and Win98 on a dual boot so I could actually use DirectX if I rebooted into 98.
After 6 months I got incredibly sick of that setup and went to Win2K (but now I have no excuse to ignore DX coding… damn)
Nice catch Chris Bond. Kind of a mismanagement with my backup files, I think.
It’s kind of weird but some of the time, the icon is displayed. Try making a copy of glu32.dll, rename to glu32_130.dll, and put it in system32 folder. If all else is fine, it should run.
Knackered, I don’t use DX in any way, even thought I have DX8 wrapper., so check mate.
//edit// I meant the icon is displayed on my system when I tried removing a DLL.
V-man
[This message has been edited by V-man (edited 07-16-2002).]
Because I have a folder called junk, in which I place DX related stuff, and it needed some files in there. I should change the folder icon to a hazardous waster symbol.
Nope doesn’t work… because the names the .cpl is looking for are mangled ("_gluPickMatrix@36", for example) so they don’t exist in the regular GLU32.dll :
more clearly:
Functions that the .cpl is looking for in GLU32.dll:
gluDeleteTess
gluNewTess
gluTessBeginContour
.
.
.
gluTessVertex
All of these do, in fact, exist in GLU32.dll, and are being resolved correctly.
Functions the .cpl is looking for in GLU32_130.dll:
These functions do not exist (at least, not by these names) in GLU32.dll, therefore simply renaming it to GLU32_130.dll doesn’t help - sorry!
You pretty much need to either distribute the GLU32_130.dll or recompile your .cpl without the above dependencies.
Again, I’m only ~25% sure this is the actual problem… control.exe would have to be pretty savy to notice this before the .cpl was actually running. But since it runs on Win98/NT that’s the only thing I can think of.
I didn’t realize the upper right window showed the functions being used. What’s odd is that I’m not using the GLU tesselator.
If you open opengl32.dll, you will see it has a DEPENDENCY on glu???
