tags:

views:

80

answers:

6

I have a dll which is dependent of OPENGL.DLL . However, Windows comes with OpenGL32.dll . I want to change this dependency name in the dll binary so it looks for OpenGL32.dll instead. I tried opening it in VS's binary editor but I cant seem to make the name longer. I can for instance change it to OpenDD.dll but I cant add to it. How could I do this?

Thanks

If I edit it to be like OpenGLAA or OpenGLJU this works but changing to OpenGL32 results in it saying

.dll cound not be found

+2  A: 

You could try making a copy of OpenGL32.DLL, naming it OPENGL.DLL instead of editing the binary that refers to it.

It seems likely OPENGL.DLL and OpenGL32.DLL are different versions, and thus you won't be able to swap one for the other.

Adrian McCarthy
Nope, it works and I want to change it to Opengl32 to avoid shipping OPENGL.dll with my app
Milo
A: 

You could set the dependency to some name that fits, then create another DLL by that name that forwards all the relevant names to opengl32.dll. From a purely technical viewpoint of directing the calls to OpenGL32.DLL, there should be no problem (other than the fact that it continues to require an external DLL that you may prefer to avoid). If you really need to change the dependency directly to OpenGL32.dll, it's going to be quite non-trivial. For most practical purposes, you need to duplicate most of what the linker does to produce the executable in the first place -- that's theoretically possible, but calling it non-trivial is a serious understatement.

Jerry Coffin
But it is working, and this solution envolves creating another dll dependency and avoiding dependencies is my point of doing this :p
Milo
@Jex: see edit. The real question is how and why you're producing something that depends on `opengl.dll` in the first place.
Jerry Coffin
+4  A: 

You might want to experiment with creating a "forwarding DLL" named OPENGL.DLL that simply forwards to the OpenGL32.dll:

Of course, this assumes that the APIs have the same signatures. If not, then you could write a wrapper OPENGL.DLL that has the right API signatures, then turns around an calls the OpenGL32.dll functions. That might be a tedious task if there's a lot of functions, but if there are differences in the API, something will need to be there to handle those differences.

Michael Burr
+1  A: 

Don't hex edit your .dll, just link to the correct version of opengl. From http://www.opengl.org/resources/faq/technical/gettingstarted.htm#0010:

If you see files such as opengl.lib and glut.lib, these are SGI's unsupported libraries for Microsoft Windows. They should not be used. To use hardware acceleration, the Microsoft libraries are recommended. More info on the SGI libraries can be found here. Always link with either all Microsoft libraries (e.g., glu32.lib, glut32.lib, and opengl32.lib) or all SGI libraries (e.g., glu.lib, glut.lib, and opengl.lib). You can't use a combination of both Microsoft libarires and SGI libraries. However, you can install both sets of libraries on the same system. If you use SGI's .lib files, you'll need the corresponding .dll files installed in your system folder. (i.e., linking against opengl.lib requires that opengl.dll is installed at run time).

MSN
My problem is glu32 crashes while glu does not
Milo
@Jex, what is the crash? Callstack, etc.?
MSN
A: 

Uh, NEVER rename a system DLL for YOUR purposes.

If you do ANYTHING, COPY it to your .EXE folder and rename it to something like OpenGLMYHACKEDVERSION.dll. This way it would be IMPOSSIBLE for another app looking for the REAL system .dll to use "your" version of it.

franji1
+1  A: 

Its a bit hard to explain in english how to change the imported dll name in PE (there're quite a few levels of indirection and RVAs), but accidentally, I have a library that can be used for stuff like that. PE32 only, though.

So here's the utility which you can use: http://nishi.dreamhosters.com/dllrepl_v0.rar (with source). And here's how it works: (UpdateImports() does the thing)

struct PE_Hdr1 : PE_Hdr {

  void UpdateImports( char* s1, char* s2 ) {
    int c,i,j;
    int p = 0;

    uint ofs = 0x50;
    printf( "Redirecting <%s> to <%s>\n", s1, s2 );
    // store the target dll name to some place in MZ header
    memcpy( &exedata[ofs], s2, strlen(s2)+1 ); 

    uint idtrva = tbl[1].VA;
    PE_IDRec* idt = (PE_IDRec*)&exedata[ RVA2Ofs(idtrva) ];

    for( i=0; i<nIDRec; i++ ) {
      char* dllname = (char*)&exedata[ RVA2Ofs( idt[i].DLLName ) ];
      printf( "dllname=<%s>", dllname );
      if( stricmp( dllname, s1 )==0 ) {
        printf( " -> <%s>", s2 );
        idt[i].DLLName = ofs;
      }
      printf( "\n" );
    }
  }

};

// Usage: dllrepl file.exe file_out.exe msvcrt.dll msvcrt32.dll
int main( int argc, char** argv ) {

  if( argc<5 ) return 1;

  FILE* f = fopen( argv[1], "rb" ); if( f==0 ) return 1;
  FILE* g = fopen( argv[2], "wb" ); if( g==0 ) return 1;

  MZ_Hdr mz; PE_Hdr pe;
  PE_Open( mz, pe, f );

  ((PE_Hdr1&)pe).UpdateImports( argv[3], argv[4] );

  fwrite( pe.exedata, 1,pe.exesize, g );

}

The new location for dll name is somewhat hackish, but with allocation of a safe area in a PE it would get much more complicated.

Shelwien