Jump to content


Trick to replace opengl32.dll can't seem to overwrite it.


7 replies to this topic

#1 Nicholas Christopher

    Member

  • Members
  • PipPip
  • 77 posts

Posted 23 May 2007 - 01:43 PM

I'm trying to replace opengl32.dll but windows won't allow me.

Is their a trick to prevent windows or fool it somehow, or do I need to boot from a CD and replace it in DOS or something like that?

I was hoping not to have to do that.

Nicholas

#2 SigKILL

    Valued Member

  • Members
  • PipPipPip
  • 200 posts

Posted 23 May 2007 - 01:52 PM

Why would you want to do that?

If you require some special opengl implementation (like 3dfx or sgi's software renderer) then simply rename the dll to opengl32.dll and put it in the application directory. Alternatively you can load the dll dynamically.

#3 .oisyn

    DevMaster Staff

  • Moderators
  • 1842 posts

Posted 23 May 2007 - 02:50 PM

Rename it, then copy the alternative to it's original name.
C++ addict
-
Currently working on: the 3D engine for Tomb Raider.

#4 Nicholas Christopher

    Member

  • Members
  • PipPip
  • 77 posts

Posted 23 May 2007 - 03:16 PM

Here is what is happening:

I am copying opengl32.dll to the windows/system32 directory and replacing the current copy. Then windows is replacing the one I copied and restoring it back to the original.

Even when I completely delete the original, windows restores it.

I have googl'd about this problem, and I have found
only one link discussing a work-around for this problem but it won't
work for me.

The reason I'm doing this is to install a debug version of opengl32.dll

Nicholas

#5 kusma

    Valued Member

  • Members
  • PipPipPip
  • 163 posts

Posted 23 May 2007 - 04:10 PM

The simplest solution would be to put your debug-dll in the working dir of your application. That way it will be loaded instead of the standard dll.

#6 Nicholas Christopher

    Member

  • Members
  • PipPip
  • 77 posts

Posted 23 May 2007 - 05:00 PM

@kusma

I thought windows always searched the windows directories first for dll's
before searching the paths in the path environment variable.

Also If the path of your application is not in your path environment variable
It will not even be able to find the dll at all.

But I will test the path environment variable as I may be wrong on my facts

Nicholas ...

#7 SigKILL

    Valued Member

  • Members
  • PipPipPip
  • 200 posts

Posted 23 May 2007 - 05:09 PM

It always searches the 'working dir´ first before checking system and path dir's. Thats why you should put it in the app's working dir (which most probably is the same path the executable is in).

#8 Nicholas Christopher

    Member

  • Members
  • PipPip
  • 77 posts

Posted 23 May 2007 - 05:27 PM

LoadLibrary From MSDN..

If no file name extension is specified in the lpFileName parameter, the default library extension .dll is appended. However, the file name string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file in the following sequence:

1-The directory from which the application loaded.
2-The current directory.
3-Windows 95/98: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
4-Windows NT/ 2000: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

5-Windows NT/ 2000: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
6-The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
7-The directories that are listed in the PATH environment variable.


I guess this answers that, which really sucks... thanks for the post Sig.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users