Is there any way to use a 3rd party DLL without having access to the associated .h and lib files? Perhaps some way to reverse engineer the hooks so that I could use it in my application?
Dan
Printable View
Is there any way to use a 3rd party DLL without having access to the associated .h and lib files? Perhaps some way to reverse engineer the hooks so that I could use it in my application?
Dan
1) To use a library without a .lib file:
LoadLibrary()
GetProcAddress()
2) To actually use the library in any meaningful way, you need to know what those functions do, how many and types of parameters to pass, when to call those functions, etc. etc.. That information you cannot get by calling LoadLibrary or GetProcAddress, that needs to be provided as "help documentation".
Otherwise, you're putting a lot of risk into calling functions you have no real information about. What if one of those functions format's your hard drive if parameter 1 is equal to -1?
3) Why don't you have documentation to the DLL? With many DLL's EULA agreements, it is illegal for a programmer to "tap into" DLL's they have not purchased or maintained permission to use in their own programs.
Regards,
Paul McKenzie
I know the DLL is not going to format the drive, so that's not a concern. However the legal issue might be.
Basically here's the deal. I'm trying to write a program which can access the encrypted data inside a .tivo file transferred from a TiVo DVR. I discovered long ago that I could get at the video data by using a DirectShow filter provided with the TiVo Desktop application. However the only way I know of to access the metadata contained in the file is to use an open source project called tivodecode which completely circumvents the encryption and as such would be illegal to use in a commercial project. I was looking through the TiVo Desktop install directory and I found a DLL called Metadata.dll. My thought was that maybe I could tap into this DLL to access the metadata "legally" like I use the DirectShow filter to access the video data.
I know accessing a private DLL is not quite the same as using a DirectShow filter which is installed system wide, but I thought it would still be more legal then using an open source program that completely circumvents the encryption.
Dan
The point I am making is that you cannot use the DLL unless you have documentation. DLL's aren't just about function names -- you have to know when and how to call these functions, what the parameters denote, what the parameter types are, etc. In this regard, maybe a header file is necessary, since that header may contain important constants and structures that are used as parameters to the DLL functions.
Basically, you can't fly blind with DLL's. My company writes third-party DLL's. There is no way you would be able to use that DLL blindly without documentation. You can get the function names by just loading the DLL into something like Dependency Walker, but that gets you nowhere without knowing the context as to how to call these functions.
Regards,
Paul McKenzie
OK thanks for the info.
Dan
Besides, using undocumented dll might be the same illegal circumvention thing from manufacturer perspective. If I were you I would apply the request directly to sw manufacturer.
I've tried that many times. I even talked to there head of engineering at CES once and he said they'd be willing to get me something to do what I want. But they never came through. (that was 2 years ago, and many, many emails since)
Dan
So-o-o... maybe it's time to hand this issue to your management? To let them do their work? You know, emails, negotiations, phone calls, they love that!.. :)